Methods and apparatus for title protocol, authentication, and sharing

ABSTRACT

A title management apparatus resident on a first computer including a memory for storing a control program and data, and a processor for executing the control program and for managing the data. The apparatus includes a title object resident in the memory including a title structure, the title structure further comprising a content element, a set of attributes, and a set of title object security indicia. The apparatus further includes an authorization structure configured to selectively redeem the content element based at least in part on the user security indicia, and further configured to use a set of protocols. The apparatus also includes a title management structure configured to associate a user with the title object based at least in part on the user data and the title attributes.

RELATED APPLICATION DATA

This application is a continuation of and claims priority under 35U.S.C. 120 to U.S. patent application Ser. No. 10/439,629 (AttorneyDocket No. NAV1P004×4), which is a continuation-in-part of U.S. patentapplication Ser. No. 10/232,861 (Attorney Docket No. NAV1P004) and whichclaims priority to U.S. Provisional Patent Application Nos. 60/380,787,60/407,466, and 60/407,382. The entire disclosure of each of theforegoing applications is incorporated herein by reference for allpurposes.

TECHNICAL FIELD

The invention relates to an advanced title and transaction network. Inparticular, the invention provides an architecture and operation for thefacilitation of the creation, ownership, exchange, management,reselling, marketing, bartering, and auctioning of titles over anelectronic network such as the Internet.

BACKGROUND OF THE INVENTION

The Internet has become an efficient mechanism for globally distributingdigital content, such as documents, pictures, music, and other types ofdigital content. Information can now be transmitted directly andinstantly across the Internet from the content owner to the contentbuyer, without having to first convert it into physical form, such aspaper documents, compact disks, photographs, etc.

However, the advantage of easy digital communication has also alloweddigital content to be easily pirated by just about anyone with acomputer and Internet access. The combination of high-speed broadbandInternet access, digital content compression software (which reduces thesize of digital content files), peer-to-peer file trading networks(which allows users to post content files), and lack of a viable digitalrights standard, has caused the content owners to lose control of theircontent. Consequently, content owners are experiencing a loss ofpotential revenue.

The lack of a standardized and transparent digital rights managementsystem, however, is preventing a commercially viable solution fromemerging. In order for such a system to be commercially viable, thesystem should be secure both from the user's and the content owner'sstandpoint, universal so that electronic device manufactures areencouraged to engineer it into their products, and transparent so thatusers are not required to change their behavior.

Existing systems that attempt to provide confidence between buyersinclude escrow agreements, third party confirmations, third partyappraisals and other similar techniques. These systems are slow andcomplex, and they do not provide the content user with sufficientconfidence that the buyers and sellers are not illegally replicating thecontent or otherwise attempting to sell pirated copies of works.

In addition to the pirating aspects associated with sharing digitalcontent, users are burdened with less than ideal methods for legallysharing digital content. These cumbersome methods include transferringentire files to other users via electronic mail, instant messenger,peer-to-peer and other applications, or sharing hyperlinks viaelectronic mail, instant messenger, and other applications. Thesemethods can be viewed as counter productive, anti-social and evenbothersome to the users that receive or attempt to share the content.Sharing of entire digital content such as music via electronic mail is adrain on resources and inefficient to the electronic mail servers, thenetwork, and the receiving users. Sharing of hyperlinks can lead tobroken links, complex URL (Universal Resource Locator) strings, andrestrictions on the type of content that can be shared (i.e. linked to).Compatibility problems are widespread and create frustration whensharing digital content of a specific media type.

What is needed are advanced techniques for controlling the trading ofdigital rights so that the buyers are assured of an authentic copy,“fair use” is preserved for the copy, and content owners are fairlycompensated. In addition, advanced techniques are employed to provide aneasy, friendly, efficient, and adaptable method for users to sharedigital content.

SUMMARY OF THE INVENTION

The invention relates, in one embodiment, to a title managementapparatus resident on a first computer including a memory for storing acontrol program and data, and a processor for executing the controlprogram and for managing the data. The apparatus includes a title objectresident in the memory including a title structure, the title structurefurther comprising a content element, a set of attributes, and a set oftitle object security indicia. The apparatus further includes anauthorization structure configured to selectively redeem the contentelement based at least in part on the user security indicia, and furtherconfigured to use a set of protocols. The apparatus also includes atitle management structure configured to associate a user with the titleobject based at least in part on the user data and the title attributes.

The invention relates, in another embodiment, to a title method ofmanaging title objects in a first computer having a memory. The methodincludes configuring user data resident in the memory including a set ofuser security indicia. The method further includes configuring a titleobject resident in the memory including a title structure, the titlestructure further comprising a content element, a set of attributes, anda set of title object security indicia. The method also includesconfiguring an authorization structure configured to selectively redeemthe content element based at least in part on the user security indicia,and further configured to use a set of protocols; and, configuring atitle management structure configured to associate a user with the firsttitle object based at least in part on the user data and the titleattributes.

Advantages of the invention include the ability to easily andefficiently manage and share titles over a network such as the Internet.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is described with reference to the figures, in which:

FIGS. 1A-3 depict a computer network and a title management apparatusaccording to an embodiment of the invention;

FIG. 4 depicts exemplary user data according to an embodiment of theinvention;

FIG. 5 depicts exemplary title data according to an embodiment of theinvention;

FIG. 6 depicts a logical structure of the invention according to anembodiment of the invention;

FIG. 7 depicts a logical structure of the invention as deployed in anecosystem according to an embodiment of the invention;

FIGS. 8A-E depict exemplary title management displays according to anembodiment of the invention;

FIGS. 9A-B depict exemplary title creation displays according to anembodiment of the invention;

FIGS. 10A-B depict exemplary administrative user control displaysaccording to an embodiment of the invention;

FIG. 11 is a flow chart showing steps for performing a title transferaccording to an embodiment of the invention;

FIG. 12A depicts a title payment system according to an embodiment ofthe invention;

FIG. 12B depicts a title payment system with a digital lockbox accordingto an embodiment of the invention;

FIG. 12C depicts a title payment system with a digital lockbox, a titlemanager, and a title publisher according to an embodiment of theinvention;

FIGS. 13A-E depict exemplary title data according to an embodiment ofthe invention;

FIGS. 14-15 depict exemplary title management displays according to anembodiment of the invention;

FIGS. 16-22B are flow charts showing steps for performing merchanttransactions according to an embodiment of the invention;

FIG. 23 depicts a simplified diagram in which an online contactmanagement system is optimized through the redemption of titles,according to an embodiment of the invention;

FIGS. 24A-D depicts exemplary title data according to an embodiment ofthe invention;

FIG. 25 depicts exemplary title management displays according to anembodiment of the invention;

FIGS. 26-28 are flow charts showing steps for facilitating contactmanagement, according to an embodiment of the invention;

FIG. 29 depicts a title object in which a set of stub elements areemployed to optimize titles, according to an embodiment of theinvention;

FIG. 30 depicts a simplified diagram in which components of titleelement are further displayed, according to an embodiment of theinvention;

FIG. 31A-B depict simplified diagrams of components of the stub element,according to an embodiment of the invention;

FIG. 32 depicts a descriptor component, according to an embodiment ofthe invention;

FIG. 33 depicts a content component, according to an embodiment of theinvention;

FIGS. 34A-B depict a redeem component, according to an embodiment of theinvention;

FIG. 35A depicts an issuer component of a title element, according to anembodiment of the invention;

FIG. 35B depicts an owner component of a title element, according to anembodiment of the invention;

FIGS. 36-37A depict simplified diagrams of title object lifecyclemanagement steps, according to an embodiment of the invention;

FIG. 37B depicts a simplified diagram a digital lockbox, according to anembodiment of the invention;

FIGS. 38-39 depict a simplified title transaction flow, according to anembodiment of the invention;

FIG. 40A-B depict a simplified of a header component, according to anembodiment of the invention;

FIG. 41 depicts a simplified diagram of a body component, according toan embodiment of the invention;

FIG. 42 depicts a simplified diagram of a discovery process that can beimplemented on various networks, according to an embodiment of theinvention;

FIG. 43 depicts a simplified diagram of a discovery and channeltechnique, according to an embodiment of the invention;

FIG. 44 depicts a simplified diagram of a dynamic discovery and channeltechnique, according to an embodiment of the invention;

FIG. 45 depicts a simplified diagram of an endorsement andauthentication process, according to an embodiment of the invention;

FIG. 46A-B depict a simplified example of an hash authentication scheme,according to an embodiment of the invention;

FIG. 47 depicts a simplified example of a digital asset access anddistribution system, according to an embodiment of the invention;

FIG. 48 depicts a simplified example of a asset retrieval mechanism,according to an embodiment of the invention;

FIG. 49 depicts a simplified example of a title system search process,according to an embodiment of the invention;

FIG. 50 depicts a simplified example of a title object sharing process,according to an embodiment of the invention;

FIG. 51 depicts a simplified example of a mechanism to give an asset toa user, according to an embodiment of the invention;

FIG. 52 depicts a simplified example of a trading process, according toan embodiment of the invention;

FIG. 53 depicts a simplified example of a digital trading cardstructure, according to an embodiment of the invention;

FIG. 54 depicts a simplified example of a user interface allowing usersto share and mange the sharing of digital assets among other users,according to an embodiment of the invention;

FIG. 55 depicts a simplified example of the management titles and theassociated rights, according to an embodiment of the invention; and,

FIG. 56 depicts a simplified example of an abstraction layer, accordingto an embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

The invention is directed to the creation, ownership, exchange,management, reselling, marketing, bartering, and auctioning of titles.

In this context, a title is an object that may have a number of elementsand attributes including embedded digital content, ownership attributes,copy permissions, and others as described herein. A title can alsorepresent the rights to a single piece of digital content or a singleresource, or it can represent the rights to a multitude of digitalcontent and resources and in a variety of formats. The digital contentrights, such as the ability to exchange or copy, are determined by thecontent publisher. Furthermore, a title can also represent the rights toanother title or multitude of titles, which in turn express rights todigital content or resources.

Users can initiate a variety of exchanges with each other depending onthe type of title and the rules associated with that title. Theseexchanges can take the form of trades or transfers. In the case oftrades, offers can be reviewed, and then subsequently accepted,canceled, or a counter-offer can be presented. The counter-offer processcan continue until satisfaction, or until trade is canceled.

In order to help protect the integrity of the trade, a chained hashcryptographic technique is used to guarantee that only a single instanceof the title is in circulation at any one point in time. The titlemanagement and publisher structure may perform verification on thechained hash to ensure its integrity. The chained hash technique may beimplemented in such a way as to provide benefits typically associatedwith one-time password and digital cash systems. However thisimplementation may be modified to provide a high degree of integrityaround the use of titles within the ecosystem.

The chained hash technique can be combined with additional controls thatwork in conjunction with the security classification element to providevarying degrees of security for the title and the digital contentreferred to by the title. These additional controls may includecryptographic key-splitting techniques as well as multi-user andmulti-factor authentication. Security class is an element that residesin the title to convey the level of security appropriate for this title.Security class is set by the publisher based on the publisher'srequirements and rules. Security class can be used within the ecosystemto determine appropriate handling of the title. For example, a titlewith a high-security rating of 5 can force strong authentication of theuser as well as strong encryption of the digital content associated withthe title. As an example, a multi-user authentication requirement can beused for parental controls, whereby a guardian must also provideauthentication (and acceptance) on the purchase and use of a title wherea minor is involved.

The content rating system can be used by publishers to determineappropriate ratings for their content, and these ratings can be enforcedby title management and resolver apparatus to ensure guardian approval.Content rating is an element within the content element to convey arating regarding the suitability of the content. The rating system isdependent on the type of content and the regulatory factors involved(e.g. music, video, movie, etc.).

The exchange structure, specification, and rules provide the ability forthe title publisher and/or the title owner to determine the exchangecapabilities of subsequent owners of the title. For example, a titlepublisher could limit a title owner to only one trade, or even to denytrades but allow transfers. A title owner may transfer the title toanother person for a limited period of time and deny that person anyability to trade or transfer. This ability to set limitations mayoperate in conjunction with the rules structure.

A trust structure is also implemented to provide users with a simpleability to validate the digital content they receive. The truststructure may convey that the digital content was (if applicable)rightfully issued by the content publisher. Content publishers are notbound to use the trust structure for the titles they issue but in doingso can provide assurances to the buyer.

The invention is described with reference to specific apparatus andembodiments. Those skilled in the art may recognize that the descriptionis for illustration and to provide the best mode of practicing theinvention. For example, references are made to computer servers andclients, but in a peer-to-peer network, any computer is capable ofacting in either role. Likewise, reference is made to Internet protocolwhile any substantially comparable data transmission protocol can beused.

A. ARCHITECTURE

FIGS. 1-4 depict a computer network and a title management apparatusaccording to an embodiment of the invention. In one embodiment, FIG. 1Adepicts a title management apparatus 102 resident on a computer 104,comprising a title management structure 106, an authorization structure108, a resolver structure 109, a title publishing structure 110 and anumber of client computers 112-116 all coupled over a network (e.g.Internet), where each of the computers 112-116 may be owned by users ofthe system.

The users log on to title management apparatus 102 over the network andare authorized to perform certain functions and access certain databased on their ownerships and permissions, in order to manage, resell,market, barter or auction their respective titles. A digital contentfile stored within a content publishing structure 110 is redeemedthrough a pointer stored within is respective title. This pointerindicates the location of the digital content file. However, since thislocation could have changed since the title was created, a resolverstructure 109 substitutes the updated digital content file address, ifneeded.

Redemption can occur in various ways. For example, the digital contentfile could be downloaded in its entirety, or it could be streamed to oneof the client computers 112-116 and then viewed or listened locally. Ifthe digital content file is already stored locally, redemption couldallow access or playability. In the case of an online game or chatapplication, redemption of the digital content file could authorizeparticipation.

FIG. 1B depicts another embodiment in which the title managementapparatus 160 is resident on a client computer 162. A user can log on totitle management apparatus 160 directly without network access. As inFIG. 1A, the user is authorized to perform certain functions and accesscertain data based on their ownerships and permissions, in order tomanage their respective titles. In this embodiment, redemption of adigital content file only occurs within the memory of client computer162.

In another embodiment, FIG. 2A depicts a title management apparatus 202,wherein a title management structure 206 and an authorization structure208 are resident on computer 204, while the content publishing structure210 and a resolver structure 218 are resident on computer 207. Bothcomputer 204 and computer 207 are coupled over a network to computers212-216, which may be owned by users of the system. As in FIG. 1A, theusers log on to title management apparatus 202 over the network and areauthorized to perform certain functions and access certain data based ontheir ownerships and permissions, in order to manage, resell, market,barter or auction their respective titles.

In another embodiment, FIG. 2B depicts a title management apparatus 252,wherein a title management structure 256 and an authorization structure258 are resident on computer 254, while the resolver structure 268 isresident on computer 267, and the title publishing structure 260 isresident on computer 261. Computers 254, 267, 261 are coupled over anetwork to computers 212-216, which may be owned by users of the system.As in FIG. 1A, the users log on to title management apparatus 252 overthe network and are authorized to perform certain functions and accesscertain data based on their ownerships and permissions, in order tomanage, resell, market, barter or auction their respective titles.

FIG. 3 depicts the computer 310 for performing the invention accordingto an embodiment of the invention. The computer includes a processor 312coupled to a memory 314. The memory contains a data structure 316further comprising a plurality of software structures including controlprocedures 320, communication procedures 322, interaction procedures 324and data 326. The processor is further coupled to a user interface 330,an Internet communication interface 332 and a network interface 334.

FIG. 4 depicts exemplary user data 426 a according to an embodiment ofthe invention. The user data has a number of elements for each user 426a-A to 426 a-N, including personal information fields, businessinformation fields, wallet fields, privacy and security fields, andpersonalization fields. The personalization fields can be set by theuser for controlling the user environment, for example, the defaultcolor scheme for the graphical user interface, the type of interfaceskin, and the background image. Profile information maintained on theuser can include, for example, the financial information, emergencycontact, medical information, and work related information. The userdata and profiler are extensible to support the needs of the titletransaction system (and the ecosystem).

The title transaction system may provide the ability for users to managetheir profile information and to generate titles for accessing profileinformation. For example, this functionality can be used by someone toeasily create a business card title and distribute that title to theirassociates. The title in this case would be a tag that refers (that is,points) to their “business card” profile elements containing (as anexample) their name, title, business address, and business contactinformation. In an other example, some else could create an emergencyprofile card and distribute it to specific people so that in anemergency they would have access to certain personal information such asname, medical insurance number, allergies, health risks, and emergencycontacts. In this particular case, the title could be a ticket. Thetitle transaction system provides for close integration of profileinformation to provide significant value add for the user as theyparticipate in a community where communication, purchasing, trading,auctioning, and bartering are common place.

FIG. 5 depicts exemplary title data 526 b for a title object. The titledata has a number of fields for each title including header fields,titleowner fields, content parts fields, titlerules fields, and taggedfields, for example, XMLDSIG fields. The title object can be a type suchas a tag, token or ticket.

As depicted in FIG. 5, the title object has at least one stub objectassociated with it in order to verify the integrity and valid instanceof the title. In addition to identifiers, the stub object may containsecurity indicia, such as the indicia required by the chained hashtechnique, in order to validate the single instance and valid ownershipof the title. This stub object may change state on every redemption,exchange, and revocation of the title.

The title object may have more than one stub object associated with itin order to convey additional information, controls, content, or othervalue-add not explicitly given in the original title. The stub objectprovides extensibility to the title without requiring a completereplacement to the title object. As an example, a value-add resellersuch as a retail merchant may attach additional content or value to theoriginal title in order to promote their product or even to make theoriginal title more attractive for sale or trade. In another example, anadditional control stub maybe attached to the original title in order toensure appropriate handling of the title for use by minors, such asensuring that only an edited version of the content is viewed. The useof the stub object is flexible to ensure extensibility of the titleobject.

As depicted in FIG. 5, the stub object can contain a digital signatureelement in order to verify the integrity of the stub. Although the stubis viewed as an extension to the title, the stub can be digitally signedby any participant in the ecosystem. This permits a flexiblearchitecture where multiple participants can collaborate on adding valueto a title object.

The system employs a set of specification and rules for structuring,creating, managing, handling and using titles. The specification andrules, as well as the format of the title, are extensible to support theneeds of both the user and content publisher, as well as the needs ofintermediary systems within the ecosystem that handle (or interact) withtitles.

In the exemplary embodiment, a tag is a title object that can be copiedamong users, a token is a title object that cannot be copied like a tag,but can be transferred or exchanged between users, and a ticket is atitle object that is issued to a specific user, and hence cannot becopied or transferred among users.

B. LOGICAL STRUCTURE AND OPERATION

FIG. 6 depicts a logical structure 600 of the invention according to anembodiment of the invention. The primary parts of the logical structureare the processing portion 610, the data portion 650 and the dataabstraction portion 680. As shown, the processing portion 610communicates with the data portion 650 through the data abstractionportion 680. FIG. 6 represents the primary model for implementation anddeployment of the title transaction system, however the design isintended to be modular in that components can be eliminated or modifiedas required by the environment and requirements. The implementation ofthe title transaction system can take many shapes and forms. Forexample, this model maybe modified to permit operation of certain TTScomponents within a limited resource computing device such as a mobilephone. In another example, a fixed implementation may eliminate certainabstractions when knowingly operating in a static environment with alimited set of titles. In another embodiment, the TTS comprisessub-systems within other applications to support titles and transactions(i.e., media players such as Microsoft Media Player and Winamp,Microsoft Outlook, etc.)

A channel support structure 612 is responsible for communicating withusers and is associated with the communication procedures 622. Thechannel support 612 communicates over the network using a number ofpossible protocols including HTTP (hyper-text transfer protocol), SMTP(simple mail transfer protocol), SMS (short messaging service) andothers.

The title protocol may define a standard set of protocol bindings todescribe how title transactions are communicated across those protocols.However the title protocol specification may define extensions so thatthe title protocol can be bound to other underlying protocols asrequired within the ecosystem. When an inbound message is received bythe channel support 612, the message is passed along to a number ofother structures that decode, transform and interact with the message.For example a transform structure 614 performs a transform on theinbound data request to conform it to a normalized application interfacefor a core title transaction application. The use of the transform layerat this point provides standardized parsing of the transaction as itproceeds through the pipeline to the core title transaction application.A tracker 616 acts as a transaction filter to maintain a log of all theinbound messages and requests. A rule structure 618 then applies anumber of possible rules to the message. The rule structure obtains itsrule sets from several sources including the title itself (as defined inthe title format), data storage through the data abstraction portion,and extensions that can support the retrieval of rules through othersources such as via the network. The rules include characteristics foreach title, for example, whether it can be refunded, exchanged, playedviewed, etc. Often, the functions that can be performed on a given titleare related to the title type. For example, in the exemplary embodiment,titles of type tag can be freely distributed to all users, titles oftype ticket are tied to a specific user and cannot be exchanged, andtitles of type token can be exchanged with other users. When a title oftype token is exchanged with another user, the user can no longer redeemthat title, and the system may disable any offline content associatedwith the title.

For instance, the content element within a title can contain anencrypted password that is not known to the user. A program for viewingor playing the offline content, such as Windows Media Player, would readthe title through an application program interface, check the rule sets,and then execute content, such as an MP3 file, using the encryptedpassword. Once a user exchanges the title with another user, the rulesets would be modified to reflect that that the user no longer hasrights to the content, and the content itself could not be played orviewed.

The rules associated to the title are developed and applied by thecontent publisher and by the user (or someone acting on behalf of theuser). The title management and title publisher modules may provide anapplication and interface to easily develop and apply rules to thetitles. For example, a content publisher may apply usage rulesapplicable to the title and the digital content and/or resource itprovides evidence of rights to. In turn, a user may apply default ruleswithin the title management module to assist in controlling andprotecting their actions related to certain titles (for example, toprevent from accidentally trading a valuable title). In another example,a parent may establish restrictions on the type of content their childmay access and use in their title management module.

Specialized rules, called triggers, may also be used. Triggers are rulesthat invoke actions that are external to the title management apparatus.For instance, a parent can be notified by email that a child wishes toredeem a digital content file for which there is some age restriction.

Specialized rules, called timers, may also be used. Timers are rulesthat invoke actions based on a specific time or based on a spent amountof time. For example a title may only be good for twenty four hours, oran exchange may only be valid for one week. Timers maybe combined withtriggers in rule processing.

The core title transaction application 620 (core TTS) is the applicationthat verifies the ownership of the titles by the users and thatauthenticates the titles and selectively permits the titles to betransferred if such rights are allowed. Among the modules that may becontained within the core TTS application are the following:

-   -   (a) A title manager module performs management functions on        titles such as organizing, deleting, adding, transferring,        trading, copying, backing up, viewing, and redeeming. In        addition to basic title functionality, the title manager module        can provide sophisticated and value-add features to allow the        user a better online experience such as chat where real-time        redemption and trading are available during the chat session.        Furthermore, features such as sorting categorizing, searching        and notify can be made available to the user. As an example, a        sophisticated search capability can be implemented whereby the        user can search the network for other users, titles available        for bid, transaction makers, or even a secure and trusted third        party lockbox with which to conduct a trade. This sophisticated        discovery process may be an integral part of the TTS ecosystem.        The title manager module is the primary application component        that the user may interact with on a regular basis. The title        manager module maybe designed to be a single-user or multi-user        application depending on the specific use of the module. A        single-user version can be used in a peer-to-peer network,        whereas a multi-user version can be deployed with consumer        aggregators. The title manager implements a lockbox feature that        is responsible for securely executing trades between two        parties. The lockbox provides storage for titles being traded        and provides a secure environment where users can verify trades,        view samples, and accept a trade. Upon acceptance of the trade        by all parties involved, the lockbox may execute the trade and        provide each party with an updated title and stub object-pair        that evidences their new rights. The lockbox feature of the        title manager can be implemented as a standalone service so that        a trusted third party can provide secure execution of trades.    -   (b) A transaction tracker module performs the basic task of        tracking all inbound and outbound transactions whether        successful or not. The tracker module is configurable by the        user to determine the level of tracking to be performed based on        the user's requirements. The tracker may be used to provide a        record of all transactions performed by the user such as trades        and transfers. The tracker may be used by all core TTS        components for creating a record of all transactions (for        example, those performed by the resolver and content publisher).        The tracker may record transactions in a data repository using        the data abstraction portion.    -   (c) A rules builder module performs the task of building rules        to be associated with the titles and processing of the titles.        The rules builder module may provide an easy to use interface        for the user to create and build rules that can be embedded        within a title or used during the processing of a title. Rules        that are not embedded within a title may be stored in a data        repository using the data abstraction portion. The rules builder        may provide an extension capability to apply rules developed        external to the rules builder ensuring the adaptability of title        processing.    -   (d) A title resolver module that the important task of resolving        all titles presented. This process involves all applicable tasks        to the title presented including verifying integrity of the        title, validating the title, ensuring ownership of the title,        decoding and decrypting the necessary title elements and        retrieving the content or resource requested. The title resolver        may be responsible for executing and acting upon rules and        triggers that are applicable to the title presented. An        additional function of the resolver would be to refresh old        titles. For example, if information contained within a title        became outdated, this information could be automatically        refreshed either by replacing the title completely or by adding        a new stub object that updates the information. In addition, the        title resolver may invoke additional processes as required such        as the CODEC module.    -   (e) A state server module that maintains and verifies state        associated with the use of titles throughout the ecosystem. The        state server may work in conjunction with the title resolver in        order to verify the validity of the title and generate new stub        objects associated with the title on every redemption and        exchange. The state server may be a high-capacity,        high-availability, and high-performance system that can be        widely distributed and chained in order to perform fast        validation for titles in use. The state server may perform        functions and algorithms associated with the chained hash,        one-time password, and key-splitting techniques.    -   (f) A title publisher module performs the tasks associated with        publishing (that is, creating new titles). The title publisher        provides an easy to use interface for a user to identify,        organize, and group new content (or resources), and then        generate a new title or title template that points to that        digital content or those resources. Titles can be generated on        the fly and immediately by the title publisher which would then        invoke the title manager to store the newly generated titles.        Alternatively, the title publisher can generate new title        templates that would describe the contents of the title but        would not immediately generate a title. Title templates could be        used in a variety of ways by the content publisher, for example        by the content publisher's online shopping site to automatically        generate titles when a buyer purchases new content. The content        publisher stores work in progress (such as grouped publishing        efforts) in a data repository using the data abstraction        portion. Title publishers may provide sophisticated        functionality to enhance the online experience for content        publishers such as organizing content and title publishing into        projects, sharing projects, and allowing community projects.        Workgroup and workflow capabilities can be built into the title        publisher as well as creating single-user and multi-user        versions. As an example, a multi-user version can be implemented        by a consumer aggregator or service provider in order to perform        title publishing activities on behalf of a user community.        Enhanced features may provide additional value to people using        the title publisher such as verifying pointers to content files        and resources, automatically obtaining icons, and even pushing        titles and content out to servers.    -   (g) A rating system module performs rating tasks on transaction        records to support billing requirements. The rating system may        be flexible to support the variety of billing options required        within the ecosystem. The rating system may act on transaction        data but may maintain separation between the data sets to ensure        integrity of the transaction log.    -   (h) A CODEC module performs coding and decoding functions on the        content retrieved by the title resolver. The primary purpose of        this module is to encapsulate content in a secure package as        determined by the security required of the title and established        by the rules. For example, this module can perform digital        watermarking of music and image content, and it can also be used        to encrypt the content in a traditional digital rights        management package. Additionally, the CODEC can be used by the        resolver to decode contents within the title before processing        by the resolver. The CODEC may provide mechanisms to support        these functions as required within the ecosystem.    -   (i) A billing interface module provides an interface to the        billing system operated by the user or entity running any of the        core TTS components or modules.    -   (j) A transaction viewer module provides an interface for the        user to view transactions recorded by the transaction tracker.    -   (k) A content interface module performs the tasks associated        with retrieving the content. This module may generally be        invoked by the resolver. The content interface module may be        extensible to support a variety of content and resource systems        in use by content publishers.    -   (l) A synch & replication module performs synchronization and        replication across components and modules within the TTS system.        This is required for a number of functions including (but not        limited to) synchronization and replication of transaction log        entries, synchronization of titles across title management        modules in a highly distributed environment, and replication of        title databases to support redundancy and high-availability.    -   (m) A crypto interface module performs symmetric and asymmetric        cryptographic functions as required within the TTS ecosystem.    -   (n) An authentication and authorization module performs the type        authentication and authorization required by (and specified by)        the title or other ecosystem configurations. Authentication may        not be required in certain instances, or can be as simple as        providing an identifier for “free” use. Strong authentication        may be required for other instances and may be enforced by the        ecosystem components. Strong authentication can take the form of        two-factor such as Smartcard and PIN, or via mobile phone using        a SIM card and a PIN, or via any other supported method such as        a SecurID token card. In basic form, authentication may be a        username and password. Authorization may provide fine-grained        access control to core TTS applications as well as to use titles        within the ecosystem. Authorization may be based on rules        established within titles and configured as part of the        implementation of core TTS applications.    -   (o) A payment interface module provides an interface to a        payment system operated by a user or entity of the core TTS        components and modules. This permits real-time and batch        processing of payment requests as configured by the user or        entity.    -   (p) A cache management module performs basic caching functions        of the content or resources retrieved by the title system. This        function may provide performance benefits using cached content        versus retrieving new content on every request for the same        content.    -   (q) A user registration module performs registration of new        users into the core TTS components and modules. This may be used        to establish new users in a single user environment such as        peer-to-peer, as well as establish new users in a multi-user        environment such as that hosted by a consumer aggregator. A        consumer aggregator is an entity that provides services to a        consumer base (i.e., ISP, mobile operator, etc.).    -   (r) A transaction maker module performs transaction maker        functions such as operating an exchange for the sale of titles,        perform licensing of content represented by the titles,        maintaining a book of trades, closing and clearing trade        transactions, and performing additional value add as determined        by the market.    -   (s) An intelligent data retrieval and query module integrated        with the data abstraction portion in order to perform        intelligent searches and queries on a variety of data in a        variety of disparate locations. The IDRQ module can combine,        map, and match data before presenting it to requesting        applications through the data abstraction portion. Persistence        and caching can be developed into the IDRQ module to enhance        performance on multiple and frequent queries/searches.    -   (t) A web crawler module performs searches on the web to catalog        content and provide a mechanism to automatically generate titles        that represent the content that has been discovered. The web        crawler module can be used statically or dynamically executed        based on configuration of the implementation and/or on inbound        requests. The web crawler module could interface with the        intelligent data retrieval and query system attached to the data        abstraction layer for intelligent searches and retrieval of web        content.    -   (u) A discovery mechanism that can be used by all appropriate        modules for discovering TTS resources that may be available on        the network. The discovery mechanism may allow TTS modules to        participate in a peer-to-peer environment as well as collaborate        on activities. The discovery process can ensure that trust third        parties are available for conducting secure transactions and        well as simplifying the user and content publisher experience        for clearing titles through the ecosystem.

In the outbound stream from the core TTS, the rules structure 618 thenperforms certain functions on the outbound information according torules stored in the data 650 and/or embedded in the title. The tracker616 checks to ensure that the outbound information matches the inboundrequests so that no inbound messages are dropped or ignored and thatoutbound message are responding to legitimate inbound messages. Thetracker may log transactions in accordance with the configuration. Thetransform 614 converts the outbound information from a normalized formatinto a format that conforms to a user profile or preference, as well asbased on incoming requests for particular transforms. For example, thedata can be transformed into WML for display on a WAP enabled phone, orinto HTML for display on a web browser. Certain transforms can beexecuted based on rules established within the system. The profile orpreference data as well as the transform templates are retrieved fromthe data portion 650 in order to perform the transform. Finally, thechannel support 612 communicates with the user of the network in anative protocol format.

In another embodiment, FIG. 7 depicts a logical structure of theinvention as deployed in an ecosystem according to an embodiment of theinvention. The ecosystem 702 is comprised of a number of entities, eachproviding a service of benefit to the overall system, and each connectedto the other using some type of network protocol.

The title manager 712, content publisher 714, transaction maker 718,content creator 716, and hosting provider 720 are coupled to each otherusing a network protocol 724 such as TCPIP over the Internet. The clientdevice 704 can be coupled to title manager 712, content publisher 714and transaction maker 718 using any one of a number of networkprotocols. Among these are HTTP 706, E-Mail (SMTP) 708, and SMS 710.

Initially, the content creator 716 creates a digital content file, suchas an MP3 song, as well as a title associated with the digital contentfile. The creating user interacts with a display as shown in FIG. 8A anddescribed in detail below. The digital content file is transmittedacross the network protocol 724 to hosting provider 720, where it isstored until a content publisher 714 desires to make it available tousers with a client device 704. The content creator also transmits thetitle to the title manager 712 using network protocol 724.

Users desiring the digital content file may access the transaction maker718 using the client device 704. Transaction maker 718 functions as amarketplace where digital content buyers and sellers can transact witheach other in a secure environment. When a user agrees to buy thedigital content file from a seller, in this case the content publisher714, the transaction maker 718 communicates this to the title manager712, which in turn, modifies the title of the digital content file withthe new rights just purchased by the user. The user can now redeem thedigital content file from the content publisher 714 and download it tothe client device 704.

If the user desires to transfer the title to a new user, and the title'ssecurity indicia allows it, the user can become a digital content sellerand post an offer to transfer the title on transaction maker 718. Asbefore, when a new user agrees to buy the digital content file from theuser, the transaction maker 718 communicates this to the title manager712, which in turn, modifies the title of the digital content file withthe new rights just purchased by the new user. The buyer can now redeemthe digital content file from the content publisher 714 and download itto the client device 704. The seller can no longer access the digitalcontent file on the content publisher 714.

FIG. 8A depicts an exemplary title management screen display 800according to an embodiment of the invention. This display is used by auser to perform certain functions and access certain data based on theirownerships and permissions, in order to manage, resell, market, barteror auction their respective titles. The display is divided into twosections, a title folder pane 806 and a title content pane 802. Thetitle folder pane 806 can further organize the titles into folders basedon different attributes, such as the type of digital content, such ascontacts, games, movies, music, playlists, and unsorted. Furthermore,deleted titles are placed a deleted folder. The title content pane 802displays more detailed information about the digital content. In thisexample, the user selected title abc@company.com 808 in the title folderpane 806, and is displayed the corresponding business card 804 for acontact “Jim Smith.”

FIG. 8B depicts an exemplary title management screen display 810according to another embodiment of the invention. As in FIG. 8A, thedisplay is divided into two sections, a title folder pane 806 and atitle content pane 802. Each title entry 812 in the title content pane802 may have a play user selectable button 813, a trade user selectablebutton 814, and a delete user selectable button 815.

In this example, the user selected mySongArtist#3 814 in the titlefolder pane 806, and is displayed the owned titles to mySongArtist#3songs 812. From this display, the user has the option to play 813 thesong on the user's client computer, trade 814 the title to the song toanother user, or delete 815 the title altogether.

If the user selects one of mySongArtist#3 songs 812, a more detailedtitle content pane 842 appears, as shown in FIG. 8C. In this pane, adescription of the song is displayed, along with the music type,category, and rating. A picture, such as an album cover, can be alsodisplayed. As is FIG. 8B, the user has the option to play 813 the songon the user's client computer, trade 814 the title to the song toanother user, or delete 815 the title altogether.

For example, if the user chooses to trade 814 mySong#3, a tradePreparation pane 862 appears, as shown in FIG. 8D. Aside from theinformation that was previously displayed in the title content pane 842of FIG. 8C, additional information is displayed, such as a valid fromdate field 871, a quantity field 872, a value field 873, and an exchangelimit field 874. The user can also view a sample 875 of mySong#3.

The user must select whether to trade or transfer 864 the title ofmySong#3 with another user. Additionally, the user may be asked if theywould like to list it on a barter site (“list on barter site”) or postit to a transaction maker site (“post to transaction maker”). The usercan enter description of the mySong#3 in the description field 866, aswell as a note in the Personal Note field 870 to the user with whom thetrade is being transacted. In the trade with whom field 868, the userenters the e-mail or mobile phone number of the user with whom they wishto trade. Once this information is substantially complete, the userselects the user selectable button trade title 872 to proceed, or theuser selectable button cancel 874 to cancel the transaction.

The e-mail and mobile phone numbers are used to provide examples ofidentifying trading parties. The title transaction system has beendesigned with a flexible and extensible title format to accept andsupport a variety of naming schemes, including but not limited to domainname, phone numbers, X.500 naming, and LDAP.

FIG. 8E depicts an exemplary title trades screen display 880 accordingto another embodiment of the invention. This display shows the currentstatus of a user's title transactions. The display is divided into fivesections, a title folder pane 890 a title status summary pane 882, atitle bid pane 888, and a title offered pane 884, and an action panewith a series of user selectable buttons: counteroffer 891, cancel 892,and trade 846. In this example, the user selected mySong#3 883 wasoffered to trader#2, who has been notified. Once trader#2 makes an offerfor trade, the user can counteroffer 891, cancel 892, or trade 846 andcomplete the transaction.

FIG. 9A depicts exemplary title creation screen display 900 according toan embodiment of the invention. The number of digital content files thata title can contain is substantial. Furthermore, the addressing orreferencing scheme used by the content element is flexible to supportnumerous simple and complex structures such as URL's, objectidentifiers, domain names, alternate pointers, complex multi-partpointers, and even embedded content. With embedded content, the titleactually contains the content and can optionally support a variety ofencoding and encryption schemes

The display is divided into two sections, a new project pane 902, and aproject list pane 908. A project is a set of digital content files thatshare the same title object. If the user opens myprojectName#3, 910 forexample, a project detail display 920 appears, as in FIG. 9B.

FIG. 9B depicts an exemplary project detail display 920 according toanother embodiment of the invention. The display is divided into foursections. The first is an action pane 955 with a series of userselectable buttons: delete 956, publish 958, create titles 960, and Back962. The second is an add file pane 953 with a user selectable buttonadd files 954, and a field to enter the directory in which the files arestored 952. The third is a project list pane 908. And the fourth is aproject detail pane 921.

Digital content files can be quickly added to a project by entering thename of the directory in which they are located into user input field952, and selecting the add files user selectable button 954.Furthermore, information contained in the title is shown and can bemodified through fields the project detail pane 921 such as: name field922, creator field 924, type field 928, category field 930, descriptionfield 932, location field 934, quantity field 936, value field 938, mimetype field 940, rating field 942, sample at field 944, and icon field946. When the users wish to save the information in the title, the userselectable button update 948 is selected.

FIG. 10A depicts an exemplary administrative screen display 1000according to another embodiment of the invention. This display is usedto store administrative information about each user, preferences tocustomize the user interface, and custom rules that the user wantsapplied. The display is divided into 5 tabs: personal 1002, business1004, financial 1006, emergency 1008, and preferences 1010. Thepreferences 1010 tab further contains the following fields: backgroundimage 1012, search page 1014, favorite music site 1016, favorite moviesite 1018, and favorite school site 1020. When the users wish to savethe information in the profile, the submit changes 1022 button isselected.

The business tab 1032, as shown FIG. 10B, contains the following fields:company came 1034, web site 1036, work phone # 1038, work email 1040,job title 1042, and work address 1044-1046. As in FIG. 10A, when theusers wish to save the information in the profile, the submit changes1022 button is selected.

FIG. 11 is a flow chart showing steps for performing a title transferaccording to an embodiment of the invention. Initially, the user logs onthe title manager computer 1152 and uploads a new title and associatedcontent record 1154. The user then creates attributes for each record1156. The user then posts an offer to transfer the title on transactionmaker 1158. A buyer who desires the digital content file requests thetitle from the seller 1160, whereby both the buyer and seller areauthenticated. The title integrity is verified and a new chained hash isissued 1162, authorizing the transaction. When this is accomplished, thetransaction is complete 1164.

C. METHODS OF FACILITATING MERCHANT TRANSACTIONS

FIG. 12A depicts an exemplary diagram according to one embodiment of theinvention, in which an online payment system is enabled through theexchange of titles. This embodiment addresses the importance of onlinepayment systems for Internet merchants, since direct human interactionwith customers is both costly and often inconvenient.

Current online payment systems commonly require bank cards, such as Visaor Master Card. In order to complete a purchase, customers must enterthe bank card account information, along with personal contactinformation, into an online form at the merchant Internet site. Often,the information is stored by the merchant to simplify future customerpurchases. For instance, instead of having to re-enter the information,the customer can just authenticate with a login and password, andcomplete the purchase.

Customer fears about data security and confidentiality, however, haveinhibited ecommerce growth. And although security systems have greatlyimproved, criminal sophistication has also increased. Customers are notonly inconvenienced with having to enter and re-enter accountinformation at every merchants site, they are also concerned withpropagation of their account information, protection of their privacy ateach of the merchants site, and tracking of their habits and activitiesonline.

Because of the distributed and anonymous nature of the Internet, onlinemerchants are prone to both fraudulent bank card transactions andmalicious hacking attacks. These same merchants, however, cannot remainin business if their attempts to increase security result in unintendedcustomer frustration. Modern payment systems must both enhance thecustomer buying experience and be secure. A modern payment system mustalso support anonymous payment methods similar to the physical cashschemes that are currently in use throughout the world.

FIG. 12A is an exemplary diagram of a title payment system. The systemin FIG. 12A comprises a consumer's device 1202 connected to an online,hosted digital commerce engine (DCE) 1204. The DCE is a hosted servicethat operates a title publisher 1206 and a title manager 1208. The DCEis typically hosted by a network provider such as an internet serviceprovider, application service provider, and/or mobile operator. Thetitle manager 1208 provides wallet functionality in order to handle thevarious payment processes and payment titles. The system in FIG. 12Aalso comprises a merchant site 1210, third party digital lockbox 1212,title enabled payment provider 1214, and a traditional payment provider1216. In this example, all communications occur over a TCP/IP network1201 but can be implemented using any number of protocols andcommunication implementations.

Consumer's device 1202 presents the user interface of the online titlemanager and wallet through which titles and digital content files aremanaged, transacted, and delivered. The device can be almost any type ofcomputing device that can communicate with the DCE, including desktopcomputers, laptops, PDA's, and mobile phones. The title manager 1208located in the DCE provides title management services to the consumersuch as adding, viewing, and trading titles. Additionally, the titlemanager 1208 provides wallet functionality for viewing accounts,currencies, and receipts as well as handling payment processing onbehalf of the consumer. Optionally, the functionality offered by boththe consumer's device and the DCE can be packaged in a number of waysincluding a completely integrated application to be run on a consumer'sdevice such as a desktop computer.

The merchant site 1210 is an online merchant system that provides bothweb-based and e-commerce functionality such as catalog, productinformation, product configurators, shopping pages, shopping cart, andpayment services. While only one merchant site is shown in the diagram,the invention can support any number of merchant sites. The merchantsite 1210 is further comprised of title-enabled components as shown inFIG. 12B. As shown in FIG. 12B, the merchant site can include a titlemanager 1210 a, title publisher 1210 b, digital lockbox 1210 c, andtitle merchant plugin 1210 d. All components are optionally operated bythe merchant but are generally available to merchants that are titleenabled. The title manager 1210 a provides the merchant with managementfunctions for titles that they own or potentially for customers. Thetitle publisher 1210 b allows the merchant to publish titles such as thetitles that may be given to customers that reference customer's rightsto digital content file s. The digital lockbox 1210 c is an examplewhere the merchant hosts the lockbox for trading purposes instead of athird party service. The title merchant plugin 1210 d provides paymentsupport services for the merchant including communication with digitallockboxes, title verification, and an interface with payment providers.While only one component of each type is shown, the invention cansupport any number of components to be hosted by the merchant.

The third party digital lockbox 1212 in FIG. 12A is an application thatprovides a temporary and secure safe harbor for all transaction titlesuntil title rights are established. While only one digital lockbox isshown, the invention can support any number of digital lockboxes. It isgenerally hosted somewhere in the network by the merchant, or a trustedthird party escrow service. For instance, a title may be released to theconsumer from lockbox 1212 once the purchase is completed. As shown inFIG. 12B the merchant site can also host a digital lockbox 1210 c toprovide a mechanism for supporting the payment process, that issupporting exchange transactions, in lieu of a third party service.

The title enabled payment provider 1214 is an online payment providerservice that is title enabled, in that they can support title basedtransactions. While only one title enabled payment provider is shown,the invention can support any number of title enabled payment providers.In addition to supporting titles, a title enabled payment provider 1214would provide services typical of a payment provider such as paymentprocessing, gateways to payment networks, and merchant accounts. Asshown in FIG. 12C a title enabled payment provider 1214 can operatetitle-enabled components such as title manager 1214 a, title publisher1214 b and digital lockbox 1214 c. These components would provide thesame services to the payment provider as similar components provided tothe merchant site 1210.

Each of the system elements shown in FIG. 12A, FIG. 12B, and FIG. 12Care coupled to the other using a network protocol 1201, such as TCP/IPover the Internet. Furthermore, consumers can access online titlemanager 1210 a functions directly within merchant sites 1210 if they arepermitted. For instance, payment options shown at the merchant sitereflect those available in the online title manager 1208, but otheroptions can be added.

As previously described, a title is an object that may have a number ofelements and attributes including embedded digital content, ownershipattributes, and copy permissions. In this example, a consumer wishes tobuy a product or service from a merchant using a title transaction. Apurchasing transaction generally comprises two or more separate titles:a product title or titles being offered by the merchant; and a paymentslip title or payment titles being offered by the consumer. The producttitle or titles give the title owner specific rights to the product, forinstance, the ability to play a song. The payment slip title is afinancial instrument that authorizes a payment provider to pay themerchant for any product titles purchased. Once the transaction iscomplete, the consumer would be in possession of the product title ortitles and the merchant would be in possession of the payment slip titleor payment titles.

For instance, a customer would use a web browser on customer's device1202 to access a merchant site 1210 through online title manager 1204.When the merchant site determines that the transaction is title-enabled,it presents the product title choices and displays the consumer's titlepayment options. Once items are selected for purchase, the merchant siteplaces the product titles in a digital lockbox 1212, generates apre-filled sales order title comprising transaction details including atransaction number, product title information, purchase detail, andinformation on the digital lockbox 1212. The sales order title functionsas an electronic invoice or promise of payment for the merchant 1210.

The sales order is transmitted back to title manager 1204 and stored forthe consumer to view, select payment type, and approve using theconsumer device 1202. Once approved by the consumer, the title publisher1206 may generate a payment slip title using the sales order title as aguide. The payment slip title is transmitted to the digital lockbox 1212and the merchant 1210 is notified. The merchant 1210 verifies thepayment slip title in the digital lockbox 1212 and completes thetransaction by releasing the product titles to the customer. A receipttitle can also be generated and included in the transaction if requestedor required. The merchant 1212 then captures payment from the customerby forwarding the completed payment slip title to the title paymentprovider 1214 for payment. Alternatively, the merchant 1210 can use astandard collection process such as that used for credit cardprocessing, and deal directly with a traditional payment provider 1216.

FIGS. 13A, 13B, and 13C depict exemplary payment transaction datastructures according to an embodiment of the invention. Each datastructure is maintained within the online title manager 1204, 1210 a,and 1214 a, previously displayed in FIGS. 12A, 12B, and 12C.

FIG. 13A displays an account title 1301. In this example, an accounttitle represents a bank card or a debit card. Each account title 1301can further contain sub-elements such as access information and otheraccount details. The structure of an account title 1301 is that basicaccount information is contained in a standard title block 1302 anddetailed account information is contained in a content stub 1303.Containing the detail in a content stub 1303 provides additional controland flexibility of what information is displayed, transmitted, andshared through a transaction. An account title is generally a ticketsince it is issued to a particular person and cannot be traded. This isindicated in 1302 and as is standard with tickets an authenticator stub1304 is included.

FIG. 13B displays a currency title 1310. Unlike a bank card, a currencyfunctions as a pre-paid card or traveler's check that can be redeemed atthe issuing title currency merchant. Currency is purchased in the issueddenominations of that legal tender. For instance, in the case of U.S.Dollars, the denominations would be $0.01, $0.05, $0.25, $1.00, etc.Each currency title 1310 represents a specific currency and a specificdenomination such as $1.00 US. The currency title 1310 containsadditional information regarding the currency such as issuer, type, andrules associated with the currency this is indicated in 1311. Unlikeaccount titles, currency titles are generally tokens since ownership isdependent on possession and currency can be traded or transferred. Aswith all tokens an authenticator stub 1313 is included. In anotherexample of a currency title 1310, the denomination may only be valid attime of issuance, and the title can be divisible, that is the currencytitle can be used for transactions requiring smaller denominations suchas micro transactions. In this case, the currency title can contain aprocessing stub 1312 to hold processing indicia used during microtransactions.

FIG. 13C depicts an exemplary payment slip title according to anembodiment of the invention. A payment slip title 1320 is shown and isformatted similar to previous titles. The difference with a payment sliptitle is the content that it refers to and contains. The payment sliptitle 1320 has a payment detail section 1321 that contains specificinformation relating to the payment type used by the consumer. Aspreviously described, the payment slip title is generated by the titlepublisher 1206 as shown in FIG. 12A, using the sales order title as aguide. The payment detail 1321 section of the title is actual titlecontent and contains specific information relating to payment for theproduct. The information contained in payment detail 1321 may varydepending on the payment mechanism selected by the consumer such asaccount, blinded account, secure account, etc. Generally, theinformation may contain payment detail (such as amount), account name,type number, as well a basic order information including transactionnumber, merchant, date, description of product and any rules associatedwith payment. Some or all of this information maybe encoded such thatonly a title enabled payment provider 1214 or traditional paymentprovider 1216 can decode.

As described previously, a sales order title is created by the titlepublisher 1210 b operated by the merchant site 1210 as shown in FIG.12B. The sales order title is used as an invoice and sent to theconsumer's title manager 1208 shown in FIG. 12A. The consumer's titlepublisher 1206 may create a payment slip title 1320 using sales ordertitle as a guide. The sales order title is similar to previous titlesbut may instead contain sales order information within the contentelement. FIG. 13D depicts an exemplary sales order detail 1330 sectionthat would be included within a title similar to the currency detail1311 being included in 1310 and payment detail 1321 being included in1320. The sales order detail 1330 contains merchant detail 1331, ordersummary information 1332, order detail 1333, payment detail 1334, tradedetail 1335, and consumer payment logic 1336. Order summary 1332provides summary information on the order including order number, totalprice, and taxes. Order detail 1333 provides line item detail for eachproduct offered for sale, including unit and extended pricing. Paymentdetail 1334 provides detail definitions for the terms and conditions aswell as the accepted payment types such as Visa, Mastercard, bank card,and cash. Trade detail 1335 provides information regarding the trade(product titles for payment titles) such as the location of the digitallockbox 1212. Consumer payment logic 1336 defines logic statements thatcan control how a payment slip is generated. These are basicallyinstructions to the title publisher 1206 for handling specific paymentmechanisms.

FIG. 13E depicts an exemplary title data table according to anembodiment of the invention. The title data table 1340 may be used by atitle manager 1208, 1210 a, 1214 a to store all titles used in paymenttransactions. As shown in FIG. 13E, the table can contain any number oftitles including currency titles 1342, account titles 1344, sales ordertitles 1346, and payment slip titles 1348.

FIG. 14 depicts an exemplary online title manager that is displayed in abrowser on consumer's device 1202, as described in FIG. 12. The displayis divided into two sections, a title folder pane 1402 and a titlecontent pane 1406. The tile folder pane 1402 further organizes thetitles into folders based on type 1404, although only my wallet titlesare displayed. Examples include accounts, currency, and receipts. Theaccounts folder contains titles of bank cards, debit cards, and directdebit transactions. The currency folder contains titles of pre-paidcurrencies, as well as other pre-paid accounts that can be used forpayment, such as gaming tokens and cell phone minutes. The receiptsfolder contains receipts for the customer's purchases, organized bytype, such as retail and account.

The title content pane 1406 presents summarized information 1408 foraccount, currency, or receipt titles. Title content pane 1406 alsoallows the consumer to modify authorized entries within the titles. Forexample, the user has selected the dollars currency title 1412. Thisdisplays a summary of the currency amounts contained with the title, aswell as allows the user to top up the account 1410 with additionalcurrency.

FIG. 15 depicts an exemplary merchant site 1502 that would be displayedin a browser on the consumer's device 1202, as described in FIG. 12. Inaddition to common merchant site elements, such as the shopping cartitem description 1504, the consumer's title manager 1508 is displayed ina sub-window within or on top of the browser like a wallet application.In the title manager 1508, the device presents the consumer withavailable payment structures 1510, as well as a payment slip description1512 when it is received from the merchant site 1210. Using the titlemanager window (i.e. the wallet application), the consumer can select apayment structure and make payment for the products presented in 1512.

FIG. 16 is an exemplary flow chart describing the steps in which theconsumer chooses an identified account payment structure for the paymentslip title. In this example, an identified (or named) account could be aVisa credit card account where the owner of the account is named on thecard as well as the card number. This differs from a blinded accountwhere the owner and account information is not divulged. This example isintended to show a typical credit card transaction where the titletransaction system is setup to handle traditional payment mechanismsusing current, traditional payment provider networks and technologies.In step 1602, the consumer purchases a digital content file title from amerchant, such as MerchantStore.com. In step 1604, the merchant placesthe titles expressing rights to the digital content files and ifrequested a digital receipt into the digital lockbox 1212. In step 1606the merchant generates a sales order title and transmits it to theconsumer's title manager 1208. In step 1608, the consumer then selectsthe desired form of payment and if a receipt is required from themerchant. In this example, the consumer would select a Visa credit cardaccount. In step 1610, the consumer's title publisher 1206 creates apayment slip title and in step 1612 the title manager 1208 places itinto the digital lockbox 1212 which then notifies the merchant. In step1614, the merchant's title merchant plugin 1210 d retrieves the contentsof the lockbox. In step 1616, the title merchant plugin 1210 d verifiesthe payment slip title and if valid (step 1618) may verify theidentified account and funds in step 1620. If the account is valid andsufficient funds are available (step 1622), the title merchant pluginmay capture funds from the payment provider 1216 (step 1624). In step1626 the title merchant plugin sends a complete trade request to thedigital lockbox. In step 1628 the digital lockbox completes the trade byclaiming ownership over the titles in the lockbox, swapping the titles,and distributing them to the appropriate party. In this example, theconsumer may receive the digital content file titles, and the merchantmay receive the payment slip title.

FIG. 17 is an exemplary flow chart describing the steps in which theconsumer chooses a blinded payment structure for the payment slip title.In this example, a blinded account is used as the payment mechanism inorder to protect the account holders name and the account number. Theactual account in this case can be a credit card, bank card or otheraccount or even some other payment mechanism. In step 1702, the consumerpurchases a digital content file title from a merchant, such asMerchantStore.com. In step 1704, the merchant places the titlesexpressing rights to the digital content files and if requested adigital receipt into the digital lockbox 1212. In step 1706 the merchantgenerates a sales order title and transmits it to the consumer's titlemanager 1208. In step 1708, the consumer then selects the desired formof payment and if a receipt is required from the merchant. In thisexample, the consumer would select a blinded Visa credit card account.In step 1710, the consumer's title publisher 1206 creates a payment sliptitle using encoded account information (rather than clear text accountinformation) and in step 1712 the title manager 1208 places it into thedigital lockbox 1212 which then notifies the merchant. In step 1714, themerchant's title merchant plugin 1210 d retrieves the contents of thelockbox. In step 1716, the title merchant plugin 1210 d verifies thepayment slip title and if valid (step 1718) sends the encoded accountinformation to a payment provider for approval in step 1720. If theaccount is valid and sufficient funds are available (step 1722), thetitle merchant plugin may capture funds from the payment provider 1216(step 1724). In step 1726 the title merchant plugin sends a completetrade request to the digital lockbox. In step 1728 the digital lockboxcompletes the trade by claiming ownership over the titles in thelockbox, swapping the titles, and distributing them to the appropriateparty. In this example, the consumer may receive the digital contentfile titles, and the merchant may receive the payment slip title.

FIG. 18 is an exemplary flow chart describing the steps in which theconsumer chooses a secured account payment structure for the paymentslip title. In this example, a secure account is used as the paymentmechanism in order to protect the account holders name and the accountnumber. The actual account in this case can be a credit card, bank cardor other account or even some other payment mechanism. In this example,a secured account differs from a blinded account in that the secure codeused for approving the release of funds is obtained by the consumerrather than the merchant. This example is intended to show theflexibility of the title transaction system in supporting a variety oftransaction processes. In step 1802, the consumer purchases a digitalcontent file title from a merchant, such as MerchantStore.com. In step1804, the merchant places the titles expressing rights to the digitalcontent files and if requested a digital receipt into the digitallockbox 1212. In step 1806 the merchant generates a sales order titleand transmits it to the consumer's title manager 1208. In step 1808, theconsumer then selects the desired form of payment and if a receipt isrequired from the merchant. In this example, the consumer would select asecured account payment option. In step 1810 the consumer's titlemanager 1208 transmits the sales order to the title payment provider1214. In step 1812 the title payment provider 1214 verifies the orderand account, and if the account is valid and sufficient funds areavailable, creates a payment slip title and transmits it back to theconsumer's title manager 1208. In this example, the title enabledpayment provider's title publisher 1214 b creates the payment slip. Alsoin this example, the title enabled payment provider creates an approvalcode that the merchant can verify. In step 1814, the consumer's titlemanager 1208 places it into the digital lockbox 1212 which then notifiesthe merchant. In step 1816, the merchant's title merchant plugin 1210 dretrieves the contents of the lockbox. In step 1818, the title merchantplugin 1210 d verifies the payment slip title and if valid (step 1820)sends the payment slip title to the title enabled payment provider 1214.In step 1826 the title merchant plugin may capture funds from the titleenabled payment provider 1214. In step 1828 the title merchant pluginsends a complete trade request to the digital lockbox. In step 1830 thedigital lockbox completes the trade by claiming ownership over thetitles in the lockbox, swapping the titles, and distributing them to theappropriate party. In this example, the consumer may receive the digitalcontent file titles, and the merchant may receive the payment sliptitle.

FIG. 19 is an exemplary flow chart describing the steps in which theconsumer chooses a currency payment structure for the payment sliptitle. In this example, currency titles (such as US dollars) are used asthe payment mechanism. This is similar to a physical cash transaction.The currency can be any type of currency supported by the merchantand/or their payment provider. For example, the merchant could supportEuros or even reward points as valid currency. In step 1902, theconsumer purchases a digital content file title from a merchant, such asMerchantStore.com. In step 1904, the merchant places the titlesexpressing rights to the digital content files and if requested adigital receipt into the digital lockbox 1212. In step 1906 the merchantgenerates a sales order title and transmits it to the consumer's titlemanager 1208. In step 1908, the consumer then selects the desired formof payment and if a receipt is required from the merchant. In thisexample, the consumer would select US dollars currency. In step 1910,the consumer's title publisher 1206 creates a payment slip titlereferring to the US dollar currency and in step 1912 the title manager1208 places the payment slip title and the correct amount of currencytitles into the digital lockbox 1212 which then notifies the merchant.In this example, the payment slip title is provided but maybe optionalin currency title transactions since the currency titles are validthemselves and do not refer to a user held account. Additionally, thetitle manager 1208 can process the currency titles to ensure that theexact amount of currency titles is placed in the digital lockbox 1212.This processing depends on the currency type being supported, forinstance the title manager may need to divide the currency or go througha process where in the title manager exchanges the currency in thewallet for change. In step 1914, the merchant's title merchant plugin1210 d retrieves the contents of the lockbox. In step 1916, the titlemerchant plugin 1210 d verifies the payment slip title and if valid(step 1918) verifies the currency titles in step 1920. If the currencytitles are valid (step 1922) the title merchant plugin sends a completetrade request to the digital lockbox in step 1924. In step 1926 thedigital lockbox completes the trade by claiming ownership over thetitles in the lockbox, swapping the titles, and distributing them to theappropriate party. In this example, the consumer may receive the digitalcontent file titles, and the merchant may receive the payment slip titleand the currency titles. The merchant can optionally redeem the currencytitles to capture payment in their account as indicated in step 1928.

FIG. 20 is an exemplary flow chart describing the steps in which theconsumer purchases additional currency title using an account paymentstructure for the payment slip title. In this example the user is usinga credit card (identified) account in order to get currency titles. Instep 2002, the consumer purchases the currency title from a merchant,such as BankStore.com. In step 2004, the merchant places the currencytitle and if requested a digital receipt into the digital lockbox 1212.In step 2006 the merchant generates a sales order title and transmits itto the consumer's title manager 1208. In step 2008, the consumer thenselects the desired form of payment and if a receipt is required fromthe merchant. In this example, the consumer selects a checking account.In step 2010, the consumer's title publisher 1206 creates a payment sliptitle and in step 2012 the title manager 1208 places the payment sliptitle into the digital lockbox 1212 which then notifies the merchant. Instep 2014, the merchant's title merchant plugin 1210 d retrieves thecontents of the lockbox. In step 2016, the title merchant plugin 1210 dverifies the payment slip title and if valid (step 2018) verifies theaccount and funds in step 2020. If the account is valid and sufficientfunds available (step 2022) the title merchant plugin sends a completetrade request to the digital lockbox in step 2024. In step 2026 thedigital lockbox completes the trade by claiming ownership over thetitles in the lockbox, swapping the titles, and distributing them to theappropriate party. In this example, the consumer may receive the digitalcontent file titles, and the merchant may receive the payment sliptitle.

FIG. 21 is an exemplary flow chart describing the steps in which aconsumer uses a bank checking account title to purchase currency titles.This flow is an alternate and simplified flow to that shown in FIG. 20and is intended to demonstrate how a consumer can obtain currencysimilar to obtaining cash at an ATM. In step 2102 the consumer viewstheir bank account title using the wallet function in the title manager1208. Since this title access the consumer's checking account it wouldbe a ticket. In step 2104 the consumer redeems the bank account title inorder to get currency titles (e.g. cash). The redemption process couldbe one of many redeem methods that the bank account title supports andcould be displayed to the consumer simply as “get cash”. In step 2106the bank verifies the request, account status, and ensures thatsufficient funds are available. The bank processes this redemptionrequest because of the instructions contained within the title and inthis example the bank would be title enabled similar to the merchantsite 1210. If valid and sufficient funds (step 2108), the bank sends thecorrect amount of currency titles to the consumer's title manager 2110.If the account is invalid or insufficient funds are available, then theprocess is aborted in step 2106. In step 2112 the title manager confirmsreceipt and currency titles with the bank. If the acknowledgement isreceived (step 2108) by the bank, then the bank complete its end of thetransaction and captures payment funds from the consumers account instep 2112.

FIG. 22A is an exemplary flow chart describing the steps in whichconsumer uses a pre-pay card to purchase a currency title. In step 2202,the consumer purchases a physical pre-pay card from a merchant. In step2204, the consumer then uses the pre-pay card to purchase a currencytitle from a currency title merchant, selecting a specific currency typeand denomination, for instance, $5.00. In step 2206, the consumer entersthe pre-pay card account information into the currency title providerweb site. In step 2208, the currency payment provider verifies theaccount information with the merchant. In step 2210, if the pre-pay cardis valid, the currency payment provider generates the currency title andplaces it in the consumer's title manager wallet.

FIG. 22B is an exemplary flow chart describing the steps in whichconsumer bills the purchase of a currency title to a telecommunicationsaccount, such a mobile phone bill. In step 2222, the consumercommunicates with a title currency vendor through an SMS message or bydirectly dialing the premium number. Upon receipt or connection in step2224, the title currency merchant identifies the consumer by calleridentification. In step 2226, the currency title merchant then generatesthe currency title which is placed in the appropriate location in theconsumer's title manager wallet.

D. METHODS OF FACILITATING CONTACT MANAGEMENT

FIG. 23 depicts a simplified diagram according to one embodiment of theinvention, in which an online contact management system is optimizedthrough the redemption of titles.

The exchange of paper business cards has been a familiar part ofbusiness for many years. The advent of the Internet enabled businesscards to be digitized, and the exchange to be electronic. And while thiswas certainly easier and faster, digital business cards still sufferedfrom the static content inherited from paper business cards. Previously,there had been no optimal way to update transmitted digital businesscards short of permanently maintaining distribution lists andre-transmitting the updated digital business cards themselves.

FIG. 23 is an exemplary diagram of an online contact management system.This system is comprised of a user's device 2302, a hosted digitalcommerce engine 2303 that supports a profile manager 2304, title manager2305, and title publisher 2306, as well as an electronic mail system2307, a short message service system 2308, instant messenger system2309, and additional hosted digital commerce engine 2240. While onlythese exemplary examples are depicted, any number can be supported bythe invention. Each of the system elements is coupled to the other usinga network protocol 2301, such as TCP/IP over the Internet.

The hosted digital commerce engine 2303 (DCE) is intended to depict anexample implementation of the invention whereby the DCE hosts the titleenabled systems on behalf of consumers that use devices 2302 to accessthe DCE. The title enabled systems include the profile manager 2304 thatstores and manages the consumers profile information including theircontact information, the title manager 2305 that stores and manages theconsumer's titles, and the title publisher 2306 that generates titlesfor the DCE. In other embodiments of the invention, these title enabledsystems may reside independently of each other, or even be integratedinto a desktop application.

The electronic mail system 2307, short message service system 2308, andinstant messenger system 2309 depict external systems that can be usedto transmit and deliver titles to other consumers that may or may notuse an online title enabled solution. Each of these systems wouldtransmit Titles using their own network protocols and network systems.For example, an electronic mail system 2307 can deliver a title as anattachment to an electronic message using the SMTP protocol. Therecipient can retrieve the message using the POP3 protocol, and open theattachment in a title enabled application.

An additional hosted digital commerce engine 2310 is shown in FIG. 23 todemonstrate that consumers on separate DCEs can share contactinformation between each other. In this case the hosted digital commerceengine 2310 provides the same title enabled components and service asthe first engine 2303.

As previously described, a title is an object that may have a number ofelements and attributes including embedded digital content, ownershipattributes, and copy permissions. In this example, a contact title canredeem a single contact record, such as an electronic business card, ora contact list composed of multiple contact records, as in businessdirectory. The contact record contains information that would becommonly found in a business card, such as full name, company name,address, phone number, email, etc. The contact title comprises as apointer to the location of the contact record or contact list. That is,it directs the title management system to the specific online profilemanager 2304 upon which the contact record or contact list resides.

For instance, a contact owner creates a single contact record and storesit on a specific profile manager 2304. The owner then requests a contacttitle, which would then be generated by the title publisher 2306 andstored in the title manager 2305 for distribution by the contact ownerto users. Users could then use the contact title to redeem the latestcontact record whenever needed.

The profile manager 2304 can store any type and quantity of informationon behalf of the user including business, personal, financial,preference, and emergency information. Furthermore, any variation ofcontact titles can also be generated by the title publisher 2306 onbehalf of the user. The titles can be any number of tags, tickets, ortokens as deemed necessary by the user. For instance, a tag can bepublished that points to business contact information as describedpreviously. This tag can then be freely copied and distributed to otherbusiness recipients. By redeeming the tag, the recipient will only beable to dynamically read the business contact information from theprofile. Alternatively, a ticket can be published that points a trustedbusiness associate to financial information. This ticket can be redeemedby the business associate to dynamically read certain financial recordswithin the profile to support the users business needs. Another examplewould be to give a ticket to a spouse in order to read and updatecertain profile records.

FIG. 24A provides an example of a profile data structure 2401 that wouldbe stored by and managed by the profile manager 2304, as shown in FIG.23. The profile data will be based on a well defined schema that canvary from implementation to implementation. Generally the structure ofthe data will be flexible to accommodate a variety of information anddata types. As shown in FIG. 24A, the example data structure consists ofseveral profile sections. The personal information section 2402 providespersonal information on the user, including name, address, and contactinformation. The business information section 2403 provides businessinformation including company name, address, and contact information.The emergency information section 2404 provides emergency information onthe user such as medical insurance numbers and doctor contactinformation. The financial information section 2405 provides financialinformation on the user such as bank accounts and credit cards. Thetravel information section 2406 provides detailed information on theusers travel related activities such as preferred airlines, rewardprograms, and car rental agencies. The preference section 2407 willprovide a list of preferences of the user including system preferences,interface preferences, and notifications. Other information can becontained in the profile. Additionally, each informational elementwithin the profile can be a pointer to an external system, third partyprofile system, or even a title.

FIG. 24B is an exemplary diagram depicting a contact title. The contacttitle 2410 provides a pointer back to the profile stored in the profilemanager 2304. In this example, the contact title 2410 is a tag and canbe freely copy and distributed. Since the title is a tag it does nothave an authenticator stub. The title portion of the document containsbasic title information including issuer and any applicable securityindicia. The contact information 2412 portion of the title would becontained with content elements within a title. The contact information2412 provides basic information on the contact as well as a pointer tothe actual profile. The basic information can contain simple contactinformation for reference purposes and in the event that the onlineprofile is not available and no cached copy is available. The contactinformation 2412 portion of the title also contains a rules element thatdefines any usage rules regarding the profile such as what information,when it can be obtain, and how it maybe obtained. Furthermore, thiselement can contain a query statement or even many query statementsrestricting or opening the information available to the owner of thecontact title. The query statement or statements can be used by theprofile manager 2304 to execute queries against the profile database.The integrity of the queries can be protected within a title by thetitle infrastructure or even by an applied digital signature. Ifconfidentiality of the query is required, then an appropriate encodingstructure can be implemented and conveyed within the title.

FIG. 24C is an exemplary diagram depicting another contact title. Thiscontact title is a ticket and provides two distinct redemption methods.This differs from the previous example in FIG. 24B which had a singlequery redemption method. The query redeem method 2422 allows the ownerof the ticket to query the profile to obtain information. The updateredeem method 2423 allows the owner of the ticket to update theinformation contained within the profile. This structure provides veryfine grained control over the viewing and updating of information withina profile. It is also an efficient structure with which to implementconfidentiality policies in that certain people cannot view informationbut are allowed to enter or update information. Such a policy maybeimplemented in government agencies or even in corporations where highlyconfidential information can be entered but not viewed after it has beencommitted. The rules and query statements can be applied to the title asa whole and/or separately within the redeem methods. Since the titledepicted in FIG. 24C is a ticket it will have an authenticator stub2424.

FIG. 24D depicts an exemplary contact title table according to anembodiment of the invention. The contact title table 2423 will be usedby a title manager 2305 to store all titles obtained by the userincluding contact titles. These titles maybe stored separately fromother titles as shown in FIG. 24D or stored as one large collection ofall the user's titles. As shown in FIG. 24D the table can contain anynumber and type of contact title including tags 2425 and tickets 2427.

Contact titles can refer to individual contacts or a list of contacts,or set of lists of contacts, or even to other contact titles. Thisallows groups to be established and easily shared among members, witheach member gaining controlled and granular access to dynamic and up todate information on other members. These types of titles would besimilar in structure to the titles shown in FIG. 24B and FIG. 24C andwould also be stored and managed by the title manager 2305. The ruleswithin these titles can establish dependencies such as the user must bea member of the group in order for the title to be valid. Furthermore,these types of titles can be used between hosted digital commerceengines 2303 for collaboration, backup, and redundant operations.

FIG. 25 displays a simplified online title manager interface as would bedisplayed in a browser on user's device 2302, as described in FIG. 23.The display is divided into two sections, a title folder pane 2502 and atitle content pane 2506. The tile folder pane 2502 further organizes thetitles into folders based on the type of contact 2504. In this exampleonly contact titles are displayed since it is assumed the user would beviewing their contact information rather than viewing all titles intheir repository. Examples include friends, business, and group contactlists. Other types of categorizations can be setup by the user based onthe taxonomy of the titles. The title content pane 2506 presents thecontact details 2508 referenced by the selected contact title 2512, suchas name, company name, company address, telephone number, fax number,cell phone number, email, and a picture. If permissible, the user cansend a copy of the contact information to another associate or friend byselecting the send copy button 2510 on the interface. By sending a copy,the user is sharing the contact information and this would only occur ifallowed by the title. It is assumed for this example, that the title isa tag and can be freely copied. If the title was a ticket or token, thena shadow copy may be allowed to be shared that provides anyone with ashadow copy to have very limited contact information, but not the fullaccess privileges of the original ticket or token. This method ofsharing information is more convenient, flexible and controlled thantraditional or historical physical or electronic methods.

FIG. 26 displays a simplified flow chart describing the steps in which auser redeems a contact record (i.e. certain profile informationelements) with the contact title identifier. Each contact title has aunique alphanumeric string associated with it, called a contact titleidentifier. This contact title identifier can be expressed as a URL andby entering this URL (i.e. a string) into the address on the webbrowser, the contact title, and hence its contact record, can beredeemed, displayed, and downloaded. The user does not even need to beaware of the existence of title management system at all, simplyentering the contact title identifier into a browser. This exampleassumes that the actual title is a tag that is readily available, or theuser will be accessing a shadow copy of a ticket or token. This exampleis useful for sharing contact information outside of the titleecosystem. In step 2525, the user receives an electronic message with aURL linking to an associates business contact information. The URL is aunique identifier for the contact information and can even be printed ona physical business card. An example of the URL can behttp://somedce.com/contact?id=xxxx-xxxx-xxxx-xxxx where the id can be aspecially encoded sequence of characters that becomes the uniqueidentifier. In step 2527 the user clicks on the URL link in the emailmessage or enters the URL into the address field of their browser. Byclicking the link the user is connected to an online title manager 2305which in turn retrieves the title referenced by the unique identifier asindicated in step 2536. In step 2538 the title manager 2305 redeems thetitle. In step 2540 the profile manager 2304 verifies the title and ifvalid retrieves and returns the information according to the ruleswithin the title. In step 2542 the user views the contact information intheir browser and can optionally (if supported) save the contactinformation as a v-card, text file or other supported format.

FIG. 27 displays a simplified flow chart describing the steps in which auser views a list of their contact titles and redeems a contact title.In this example, the user is registered with the DCE 2303 and uses titlemanager 2305, as shown in FIG. 23. In step 2702, the user accesses theonline title manager through a web browser. In step 2704, the user openstheir “my contacts” page by selecting the appropriate link. In step2706, the title manager 2305 retrieves a listing of the users contacttitles and displays them to the user in a view similar to that shown inFIG. 25. In step 2708, the user selects a contact title from thedisplayed list. In step 2710 the online title manager 2305 redeems thecontact title. In step 2712, the profile manager (in another DCE such as2240) receives the request and verifies the title. If the title isvalid, the profile manager retrieves and returns the contact informationaccording to the rules within the title. In step 2714, the use views thecontact information in their browser and can optionally (if supported)save the contact information as a v-card, text file or other supportedformat.

Alternatively, the user can use an application such as a MicrosoftWindows application (e.g. Microsoft Outlook) or a Macromedia Flashapplication to access the title manager and request title listings. Inthis case, these applications can have the added benefit of cachingcontact information, to enhance performance, reduce network traffic, andwork offline. In this case, the application can retrieve contactinformation as the user requests and cache it for further reference, orcan automatically retrieve contact information in the background andupdate it on a frequent and scheduled basis. This type of support allowsthe user to remove their device 2302 from the network and still viewcontact information. Another alternative is to have the title managementfunctionality incorporated directly into the application along with thetitle data table.

FIG. 28 displays a simplified flow chart describing the steps in whichthe online title manager works with a locally run application toautomatically update locally stored contact records with contactinformation. In step 2802, the user configures the online title managerto periodically update locally stored contact records. In step 2804, theonline title manager selects the first contact title 2804. In step 2806,the online title manager uses the contact title to redeem thecorresponding contact record from the appropriate online titlepublishing system. In step 2808, the title manager updates the locallystored contact record with any changes 2808. Step 2810 determines if anymore contact records are left to update. If so at step 2810 then at step2814, the next contact record is redeemed. If not at step 2810, then theupdate is complete at step 2812.

E. TITLE STRUCTURE & MANAGEMENT

In another embodiment, a title structure is employed to optimize thedescription, creation, management and use of titles. Although, thestructure of title objects as described herein maybe representative ofcertain technologies and formats such as XML, this is only as an exampleand to demonstrate one embodiment. A title object can be represented ina number of formats including XML, ASN.1, or other proprietary formatsincluding textual and binary structures.

Although certain examples of the title structure are presented, thestructure is intended to represent any number of digital and physicalassets such as digital content, including music, images, video, andtext, as well as physical goods such as computers, cameras, vehicles,and appliances. Furthermore, a title can be used to represent virtualassets such as an online experience created through a series ofactivities and events, and can also represent currencies such as cash.In one an embodiment, a title structure can be used to represent both adigital and physical asset such as the identity of a person, whereby theperson has physical assets associated with their identity and alsodigital assets associated with their identity.

Referring now to FIG. 29, title object 2901 is displayed in which a setof stub elements 2903 are advantageously employed to optimize titles.Although several stub elements are displayed within the title object, inother embodiments, a title object may have no stub elements or may justhave one stub element.

In one aspect of the invention, a set of stub elements can be coupled toa specific title, to further optimize a title's content, attributes, andsecurity indicia. In another aspect of the invention, a stub element canbe created and coupled to the title, after the title is created. In yetanother aspect of the invention, a stub element can be coupled to a setor group of titles as specified in the stubs binding information. Thispermits efficient coupling of stubs to titles.

Title element 2902 comprises a structure used to describe the title andthe content (or asset), and express the rights associated with titleobject 2901. Title object 2901 can be issued for a specified period oftime or can be left infinite. The integrity of title object 2901 can befurther protected by the use of cryptographic algorithms. In oneembodiment, a digital signature is used. In another embodiment a chainedhash is used. Information within title element 2902 can be overridden byinformation contained within stub element 2902, as long as stub element2902 was issued by the same entity as title object 2901, and furtherspecifies what information is being overridden. In another embodiment ofthe invention, the issuer of a title object can delegate authority,thereby permitting other authorities to issue stubs on its behalf.

In one embodiment, title element 2902 is the only substantial piece of atitle object 2901 that can be stored in a lockbox and inspected byparticipating parties in a trading transaction. This embodiment providesfor separation between the descriptive information provided within atitle element (2902) and security indicia, and/or content, and/oradditional value-add information that maybe contained in stub elements(2903) that are coupled to the title. As an example, an effectiveseparation permits trading parties to inspect the title that is beingtraded without comprising the security of the security indicia.

Stub element 2903 is a flexible extension mechanism to the title object2901, and can be used to convey any related and appropriate informationsuch as value-add content or additional rule processing. Each stubelement 2903 can be issued and signed by different entities and can havedifferent lifetimes. In one embodiment, stub element 2903 is optionalfor a tag. In another embodiment, an authenticator stub must be includedfor all valid tickets and tokens. The authenticator stub contains thesecurity indicia that are used to authenticate a valid instance of aticket or token.

FIG. 30 depicts a simplified diagram according to one embodiment of theinvention, in which components of title element 2902 of FIG. 29 arefurther displayed. Descriptor component 3002 comprises primarydescriptive information regarding title object 2901 of FIG. 29,including ID, type, name, description, membership, and other technicalelements used for processing. Issuer component 3003 comprises the“issuer” (e.g. the creator) of title object 2901. In one embodiment,issuer component 3003 can comprise a textual name string. In anotherembodiment, issuer component 3003 can comprise an alpha-numeric IDstring. The textual name string can be informal or formal in context toparticipating parties, and if formal, may follow standard namingconventions such as an Internet Domain Name or even an X.500Distinguished Name. Validperiod component 3004 comprises the range ofdates of which title object 2901 is valid. In one embodiment,validperiod component 3004 includes a valid from date and valid to date.This time frame can further be specified as a UTC time value.Furthermore, the validity period of title object 2901 may be extended byattaching a stub element 2902 that overrides validperiod 3004.

Owner component 3005 comprises any valid type of identity indicia incontext to the applications that create, manage, and use titles. Theidentity indicia maybe formal or informal depending on the requirementsfor the applications. For example, the identity indicia for the ownercan be a name, email, phone number, X.500 Distinguished Name, user ID,tag pointer, etc. The identity indicia can include technical detail usedto authenticate the owner. For example, the identity indicia may providetechnical detail sufficient for an application to prove identity throughthe use of X.509 digital certificates or through the use of a biometricdevice. Similarly, the invention can utilize the identity indicia toinstruct an application relying on the title to properly authenticate anowner through trusted sources such as a remote access server, or througha domain controller and rely on that trusted sources to properlyauthenticate the owner using standard means such as username andpassword. In one embodiment, owner component 3005 is optional for a tagand a token, but is required for a ticket.

Content component 3006 can comprise applicable information pertaining toan asset such as a digital content file associated with title object2901. In one embodiment, content component 3006 comprises a pointerdefining the location of the digital content file. In anotherembodiment, content component 3006 comprises a query that can be used toobtain the digital content file. Content component 3006 can furthercomprise additional information such as ID, name, creator, rating, etc.A single title object 2901, as shown in FIG. 29, can express rights tomultiple digital content files, with the information regarding each inseparate content components 3006. For example, a title object 2901 canexpress rights to a music album where the album is comprised of multiplesongs, sheet music, pictures, and lyrics. Each content piece such as asong or lyrics in this case can be described in multiple contentcomponents 3006. In one embodiment, the content component 3006 canprovide detailed information relating to a physical asset instead of adigital asset. In this case, sufficient information is contained withinthe title content component to identify the physical asset such as SIC,manufacturer, manufacturer ID, model number, serial number, etc. Inanother embodiment, the content component can contain industry ortechnology specific identifiers such as that used by the IANA,Rosettanet or even technologies specifications such as RDF.

Rules component 3007 comprises statements specifying the specific rulesthat are applied to the use of the title, as well as procedures formonitoring events associated with title object 2901, as shown in FIG.29. In one embodiment, XSLT statements are used to define the rules andare executed in a compliant XSLT processor. In another embodiment, XrMLstatements are contained within the rules component to express rightsassociated with the title. In another embodiment, application specificrules are expressed in a proprietary format within the rules component3007 and can be executed by applications that understand, interpret, andexecute the rules. In another embodiment, the rules can be expressedthrough pointers, references, and links such as the rules component 3007containing a set of URI references to rule logic contained within adictionary. The rules component can contain business logic associatedwith the title and are not exclusively used for access control,authentication, or rights expression. Business logic rules can beincorporated for additional processing, pre-processing, eventprocessing, triggers, callbacks and other business logic that maybeassociated with the title. For example, rules can be implemented toperform event processing based on a certain action being taken, or aspecific state of the title. The rules expressed within this componentcan trigger off certain state information that maybe contained withinstub components along with information contained within the title. Therules can even be used to query information on other systems in order toperform a certain event. Rules component 3007 may have attributeelements provided within its structure for properly identifying therules language that is being described.

Custom component 3008 comprises custom information desired by titleobject 2901 publisher. In one embodiment, custom 3008 can contain anytext and/or valid XML, which in turn can be referenced throughout titleelement 2901 or stub element 2902. The custom component may also containpointers, references, or links to additional information or resourcesthat are applicable to the title object.

In one embodiment, manifest component 3009 comprises referenceinformation that must be included as part of title object 2901. Forexample, if a stub element must be included along with title object2901, then it could be referenced here. In another embodiment, externaldata that must be included as part of title object 2901, can also bereferenced within the manifest component. Applications that process thetitle can also process the content or referenced content within themanifest, and in another embodiment use this manifest as part of anintegrity check of the title object.

Signature component 3010 comprises cryptographic information used toverify the integrity of title element 2902. In an embodiment of thetitle object, the signature component can be an XML Digital Signatureblock in compliance with the W3C. In another embodiment, the signaturecomponent may contain proprietary cryptographic information used toverify the integrity of the title, as well as provide functionalitygenerally associated with digital signatures.

FIGS. 31A-B depict simplified diagrams according to one embodiment ofthe invention, in which components of stub element 2902, as shown in ofFIG. 29, are further displayed. Referring now to FIG. 31A, bindingcomponent 3101 comprises detailed information on how a stub will bebound to a title or set of titles. In one embodiment, the bindinginformation can be as simple as a single title ID. In anotherembodiment, the binding information can be a complex statement where thestub is bound based on a set of properties or parameters. Anotherembodiment can bind a stub to a title or set of titles based on aspecific reference such as an XPointer. Issuer component 3102 comprisesthe “issuer” (e.g. the creator) of stub element 2902. In one embodiment,as with issuer component 3003, as shown in FIG. 30, issuer component3102 can comprise a textual name string. In another embodiment, issuercomponent 3102 can comprise an alpha-numeric ID string. The textual namestring can be informal or formal in context to participating parties,and if formal, may follow standard naming conventions such as anInternet Domain Name or even an X.500 Distinguished Name. Validperiodcomponent 3103 comprises the range of dates of which stub element 2902is valid. In one embodiment, validperiod component 3103 includes a validfrom date and valid to date. This time frame can further be specified asa UTC time value. Signature 3105 comprises cryptographic informationused to verify the integrity of stub element 2902 utilizing similarconventions to the signature component 3010 in the title element.

Referring now to FIG. 31B, stub content component 3104 as shown in FIG.31A is further described. In one embodiment, authenticator component3106 comprises information that can be used by title transaction systemapplications to authenticate title object 2901. In another embodiment,authenticator component 3106 can verify that title object 2901 is avalid, single instance of a title object. Tickets and tokens within thetitle ecosystem will have authenticator stubs associated with the titlein order to properly authenticate the title object, and validate that itis the correct instance of the title object. In another embodiment, atag or shadow title may not have an authenticator stub as it may not berequired for authentication and validation. In this example, a shadowtitle would be a title that is a “copy” of the valid and authenticatetitle, although by itself is not valid. Shadow titles, in this instance,are valuable techniques for sharing content, such that a shared titlecan still give the recipient access to sample information, or limitedcontent such as a restriction for one time only use, or access to a lowquality version of a song. In an embodiment, the authenticator stubcontains the security indicia associated with the title, and thestructure of the security indicia would be dependent on theauthentication technique applied by the publisher of the title.

In one embodiment of authenticator component 3106, a chained hashtechnique can be employed to authenticate the title. Authenticatorcomponent 3106 would contain the encrypted seed for the hash, a copy ofthe current valid hash in the hash chain, and an algorithm identifier,all of which would be used by a state server to authenticate the titlein conjunction with an index that the state server maintains. In anotherembodiment, a hash tree can be implemented within the authenticator stubto support divisible titles. The hash tree technique can be employed bytitles that represent cash or some form of currency that can be divided.

In another embodiment, stub content 3104 comprises embeddedcontent 3107,which can further include a digital content file. Embeddedcontent 3107can be also be used by issuers who wish to provide an option to theircustomers for embedding content directly into title object 2901.Advantages includes additional functionality in processing title object2901 (for example, while executing a trade only title objects areincluded in the lockbox, therefore eliminating any potential securityexposure by having embedded content directly inside the title object2901). In another embodiment, the embeddedcontent can contain textualinformation or even XML structured information.

In another embodiment, stub content 3104 comprises rules component 3108.In another embodiment, a rules component 3108 procedure can overriderules component 3007 procedure, as shown in FIG. 30. The structure ofthe rules would be similar to that of the rules component 3007 in thetitle element.

Other component 3109 comprises other functionality that may be includedin stub content 3104 and defined by the publisher of the title andunderstood, interpreted, and processed by applications involved in thetitle transaction ecosystem.

Referring now to FIG. 32, descriptor component 3002 as shown in FIG. 30is further described. Descriptor component can function as a “header”element for title object 2901, as shown if FIG. 29, and providesdescriptive information related to the title. The descriptor can be usedby system applications used in processing the title, and can be used bysystem applications involved in generic processing of titles such thatthey only interpret and act upon title specific information regardlessof the content they contain, reference, or express rights to. Forexample, a system application may only be concerned with the type oftitle that is being processed such as tag, ticket, or token. Likewise,another system application may only be concerned with the securityclassification and the priority setting associated with the title.

Titleid component 3201 comprises the unique identifier associated withthe title. In one embodiment the titleid is a GUID (globally uniqueidentifier). In another embodiment, the titleid is a unique identifierwithin all titles created by a single issuer. The identifier used intitle id can be formal or informal, registered or not registered.Titletype component 3202 comprises the type of the title object 2901such as tag, ticket, or token and states the type in this component. Thetype can be specified as a textual string element such as “Tag”,“Ticket”, or “Token”, or in another embodiment can be specified throughformal or informal identifiers such as a registered OID (objectidentifier). In another embodiment, titletype can provide a formalstructural hierarchy to the title such that title can be associated witha family of titles, and can be used to describe how the title was formedbased on a type of inheritance. The titletype would contain specifictitle-typing indicia such that the processing applications can retrieve,understand, interpret, and process properties associated with ancestortitles. In another embodiment, the titletype can be used to referencethe template that was used to create the title.

Titlename component 3203 is a short text string used to name the titleobject 2901, and is similar to a file name. Titledescription 3204comprises a longer text string, and can be used to contain primarydescriptive information regarding title object 2901, including ID, type,name, description, and technical elements used for processing.Typeofcontent 3205 comprises the type of content referred to by titleobject 2901. In one embodiment, Typeofcontent 3205 can include termssuch as “mixed”, “music” or other descriptive term. In anotherembodiment, typeofcontent can contain more formal definitions such asMIME type classifications or industry standard codes such as that usedin Rosettanet and EDI systems. Additionally, typeofcontent can be usedto specify a title content such that other titles may be embedded withinor specified by this title. In this example, a title can refer to othertitles and convey additional rules or taxonomy regarding the referred toor contained titles.

Securityclass component 3206 comprises security classificationidentifiers that can be used by processing applications. In oneembodiment, the classification can be as simple as a numerically orderedscheme that identifies the security processing level required of thistitle from an range of low to high. In another embodiment, theclassification scheme can be a registered scheme or even a moretechnically descriptive classification such as that used in ASN.1encoding schemes for X.509 certificates. Priorityflag component 3207comprises a priority indicator to be used by processing applications toapply appropriate levels of processing such is the case for servicelevel agreements, or quality of service guarantees. For example, a highpriority setting can indicate to processing applications that thistitles requires priority processing (that is, preferred status) and canbe placed at the front of the queue. In an embodiment, the priorityflagcan be textual, numerical, or structured information to be used byprocessing applications. In another embodiment, the priorityflag canprovide or reference technically descriptive service level agreementdetail that can be directly processed by applications, such as that usedin Policy Based Networks or Directory Enabled Networks.

Trackit component 3208 comprises indicators for the level trackinginformation that should be maintained by processing applications, suchas if title object 2901 must be tracked on every event. In anotherexample, the trackit component can specify that both the transactionrequest and response information be tracked in the log. In anotherembodiment, the trackit component can specify that every action must betracked in a stub element 2903 of the title object 2901. By trackingtransactions and events in the stub, the title can maintain a journal ofactivities and provide a self contained log. The logging activity withina single stub or multiple stubs can be used as a record of theactivities that comprise the titles experience. This can be used as aneffective tool for analysis and reporting, and is also an essentialaspect for titles creating and representing an experience, whereby thetitle maintains its own state. For example, a title can be used tocreate a digital treasure hunt, where the owner of the title redeems itfor each step in the treasure hunt. Completing each step requires thatthe title maintain its state and also record the activities completed bythe owner. When the treasure hunt is complete, the owner is entitled toreceive a prize. The trackit component 3208, along with the recordingability of stubs, permits the title to create this experience. The titlealso becomes a record that can prove a sequence of steps. The trackingability enabled by the trackit component 3208 and stubs can be used byrules components for fine-grained control over a title and for eventprocessing. For example, based on a specific step within an experience,the title can initiate certain actions. This would require understandingof the current state and the sequence of steps that led up to the event.

The membership component 3210 comprises title membership informationsuch as the group or family that a title may belong. In one embodimentthis could be implemented as a group identifier and in anotherembodiment this could be implemented through references.

Referring now to FIG. 33, content component 3006 as shown in FIG. 30 isfurther described. The content component is used to describe the contentor asset to which the title expresses rights. In the case of digitalcontent, the information would specifically refer to the detailassociated with that digital content such as an encoded song or video.In the case of a physical asset, the content information would providedetailed information regarding the physical asset such as location,coordinates, SIC, manufacturer, model number, part number, and/or serialnumber.

ContentID component 3302 comprises an identifier for the content. In oneembodiment, contentID component 3302 can be used to convey any type ofcontent ID used by content publishers such as DOI, OID, or a proprietaryscheme. In another embodiment, the identifier could be a serial number.Contentcreator component 3303 comprises a text string identifying thecreator of the content such as a digital content file or asset. Thecontentcreator component can be a textual string, an identifier, or evenstructured identity indicia on the creator as described in otheridentity related components such as the owner component 3005.Contentdescription component 3304 comprises a longer text string, andcan be used to contain primary descriptive information. Contentcategorycomponent 3305 comprises the categories or taxonomy of content referredto by title object 2901. In one embodiment the contentcategory can be asimple text label, while in another embodiment the contentcategory canbe a structured component with detailed taxonomy on the content referredto by the title object.

Quantity component 3306 comprises the instances of a single digitalcontent file associated with title object 2901. Value component 3307comprises the economic price associated with title object 2901. Iconcomponent 3308 comprises the computer icon to be displayed in the titlemanagement system or by processing applications.Shortform/shortformpointer component 3309 comprises a pointer to asample of the content or asset such as an image, thumbnail image, shortsample audio, or low quality audio. In another embodiment, the shortformcomponent can contain the actual sample such as textual information. Forexample, the shortform can contain a name and email address for acontact record. In this case, the shortform provides quick and immediateaccess to information, whereas the title provides access to the entirecontact information. Shortform and shortformpointer and usefulcomponents when titles are traded and shared.

Redeem 3310 component comprises methods for the redemption of the titleobject. Redemption of the title object can be obtaining the digitalcontent that the title refers to, or can also be the trading of thetitle or the sharing of the title. The redeem component is a structuredcomponent that has one to many methods describing in detail how thetitle may be redeemed. This structure is flexible to accommodate avariety of redemption processes and procedures that are required bypublishers and consumers of title objects.

Rating component 3311 comprises a content rating for the digital contentfile, such as the MPAA rating of “G”, “PG”, etc. The detail within therating component is context specific according to the content or assetreferred to by the title object. Contentintegrity 3312 comprises acryptographic message digest which is used for verification of digitalcontent integrity. The contentintegrity component provides attributes toidentify the method employed for integrity checking such as the SHA-1algorithm. Keywords component 3313 comprises a list of keywordsassociated with the content or asset. This can be used during queries,searches, and categorizations.

Referring now to FIGS. 34A-B, redeem component of FIG. 33 is furtherdescribed. Redeem component further comprises a set of methods 3402,including a query component 3404, a rules component 3405, a pointercomponent 3406, and other component 3407. As mentioned, the redeemcomponent can include from one to many methods, with each methoddescribing how the title object can be redeemed. In one embodiment, amethod can describe how the digital content maybe obtained. In anotherembodiment, a method may describe how digital content maybe obtained ina streaming version. In yet another embodiment, a method can describehow the title object can be shared, traded, sampled, archived,destroyed, communicated, or processed depending on the specificrequirements of the publisher and the consumer application. In anotherembodiment, a redemption method can be used to specify how a new titlecan created based on the current title object being redeemed. A redeemmethod may include one, some, or all of the components identified inFIG. 34B.

In another embodiment, a query component 3404 comprises searchingprocedures for the digital content file. This component has attributesto identify the query mechanism being described. In one embodiment, thequery component can contain SQL queries in order to obtain dynamicinformation from a database. In another embodiment, the query componentcan contain an XQuery statement to obtain data from an XML data set ordocument collection. In another embodiment, the query component cancontain computer executable statements to process some query businesslogic in order to calculate or process the results. The rules component3405 comprises statements specifying the specific rules that are appliedbefore, during, and after redemption. The structure and statementscontained within the rules component is similar to that described forthe rules component 3007 in the title object, in that it can contain anddescribe any type of rules statement such as XSLT, XrML, BRML; and canalso contain pointers or references to external rules. However, thisrules component is specifically associated with a redemption method.

The pointer component 3406 specifies a pointer to the content or assetbeing referenced by the title object. The pointer structure is specifiedin the component and in one embodiment can be a simple URL. In anotherembodiment this may be a URI, XPointer, XLink, coordinates or otherpointer description to the content or asset.

Other component 3407 comprises additional functionality that may beadded to the set of methods 3402. The other component accommodatesproprietary or custom information to be used during redemption andshould be understood, interpreted, and processed by applications.

Referring now to FIG. 35A, issuer component of title element 2902 asshown in FIG. 30 is further described. Issuedate 3502 comprises the datethat title object 2901 was issued. In one embodiment, name component3503 comprises a textual name string for the issuer of title object2901. As described earlier, the name component can be a formal name forthe issuer of the title such as a registered Internet Domain Name orX.500 Distinguished Name. In another embodiment, ID component 3504 cancomprise an alpha-numeric ID string for the issuer of the title object2901. As described earlier, the ID component can be a formal or informalidentifier.

Referring now to FIG. 35B, owner component 3005 of title element 2902,as shown in FIG. 30, is further described. Name 3506 comprises a textualname string for the owner of title object 2901 or as described earlierfor the owner component can be a formal name definition such as a X.500Distinguished Name. Authentication component 3507 comprises technicaldetail such as cryptographic information that can be used to verify theidentity of the title object 2901 owner. The technical information willbe sufficient enough for the processing application to correctlyidentify and authenticate the owner of the title. Information containedin this component can be cryptographic information used in processessuch as biometric identification or even for identification through theuse of digital certificates and a public key infrastructure. Component3510 comprises the activation date for title object 2901. Title objectprocessing applications may use the information contained within thevalidperiod component 3004 to ensure that a title object will not beprocessed before it becomes valid as specified in the from component3510 and not processed after it becomes invalid as specified in the tocomponent 3509. The date can be specified in the UTC date/time format.

Referring now to FIG. 36, a simplified diagram displaying title object2901 lifecycle and management steps is displayed, according to oneembodiment of the invention. Initially, a title is designed at step3602. The design process would take into consideration the sourcecontent or asset and identify properties that should be included in thetitle. The design process must also carefully consider the redemptionmethods that are appropriate for the content (or asset) and clearlyspecify the redemption processes that will be described in each method.All taxonomy, security, rule processing, business logic, and descriptiveinformation will be identified, described, and documented during thedesign phase of a title object. As an output to the design phase, atitle object template will generally be created and identified. Thetemplate is used as a technical guideline, script or set of instructionsthat can be used during the creation process to generate a title object.Templates can be stored for re-use. An application that assists orimplements the design aspects of a title can provide typical designfunctions such as collaboration, planning, scheduling, and reporting.Collaboration in title design can be an effective tool for creatingcomplex title objects that consist of multiple elements. As an example,a digital album can involve several parties for design of covers,images, audio, text, and sheet music elements. Scheduling aspects mayberequired to schedule the creation of titles. For instance, titles can becreated on demand on created in batch.

The next step in the lifecycle and management is the production orcreation stage, as shown in create title 3604. The create title 3604stage involves a “factory” or similar process to produce titles.Production can be on-demand, in bulk, or as scheduled depending on therequirements of publishers. Implementations of the create title 3604process can consider request, complexity, reporting, control, andperformance factors to ensure that production demands are satisfied.Additional functionality supported by the create title 3604 process caninclude warehousing and distribution of titles that are created.Warehousing and distribution functions can be used to service requestsby several parties involved in the title object lifecycle such as insyndication and content distribution networks. The creation process isdescribed further in FIG. 37A. The output from this stage would be titleobject instances.

The next stage in lifecycle and management is the storage of titles asdepicted in 3606. This stage would include typical title object storageand management functions including securing title objects as they arestored, properly authenticating owner's access to title objects, andviewing title objects that maybe stored. Storage functions can beimplemented as server applications or incorporated directly into clientapplications that run directly on consumer computing devices such asdesktop computers and mobile devices. Server applications can beimplemented to support a community of users. Storage of title objectscan be a critical stage in the lifecycle as a title object may tend tospend a majority of its life in storage. Therefore, it will be essentialfor applications involved in this stage to provide proper handling suchas ensuring that security requirements are satisfied.

The next stage in the lifecycle and management is the consuming oftitles as depicted in 3608. Consuming of titles primarily involves theuse of titles in order to experience the content. This is accomplishedby redeeming the title using the variety of redemption methods definedwithin a title object. Applications that are involved in this stage canbe complex as they must effectively process the title object, includingrule processing, business logic processing, interpretation ofdescriptive information, resolution of references and pointers, and mostimportantly the authentication of titles and owners. In an embodiment ofthe lifecycle there would also be the communication, interpretation andprocessing of fine-grained trust between all parties involved in thelifecycle. In one embodiment, the title manager, resolver, state server,content proxy, and content server would all be involved in theconsumption of a title object.

Consume title 3608 component can tie back to the design title 3602 andcreate title 3604 components to complete the lifecycle. In oneembodiment, the detail obtained through the consumption and use of titleobjects will be essential information used in the design of subsequentand additional titles. In another more direct embodiment, theconsumption of title can be effectively tracked and directly used by onetitle object to create a new or enhanced title object template. In thisinstance, as a title is consumed it will progressively track and updatevarious properties within its stub element structure. These propertieswill combine to represent the experience of the title object, and on aparticular redemption method will generate either a new title objecttemplate or an enhanced title object template. The new or enhancedtemplate can then be used to create additional title objects. In thisembodiment, a title can be an effective tool and mechanism for use inexpert systems or artificial intelligence engines. In anotherembodiment, a title can be used as a data source into the create title3604 process to create new titles, and this can be triggered by one ofthe redemption methods in the original title. This embodiment can be aneffective technique in using title objects for syndication ordelegation. It can also be an effective technique for transforming atitle object, enhancing a title object, evolving a title object, ormorphing a title object.

FIG. 37A is a simplified embodiment of the create title 3604 processshown in FIG. 36, according to one embodiment of the invention. Thetitle publisher/title factory 3702 is responsible for implementing theprocess that creates titles. In this embodiment, the factory receivesdata/meta-data 3704 from a content publisher and also receives a titletemplate 3706. The data and template combined may be used by the factoryto produce the title. The data 3704 portion may provide specific data tobe included in the title as well as instructions to control productions,such as the template to use, the number of titles to be produced, andthe location of where the titles are to be sent. The template 3706 canbe referenced by the content publisher and actually stored in thefactory or it can be sent by the content publisher to the factory. Thedata 3704 source and format depends on the content publisher and can beproprietary information, standards-based information, or even anothertitle object. The template can be an XSLT template or can be any formatof template instructions that can be interpreted and processed by thefactory. In this embodiment, the factory will use the template tointerpret and process the data in order to produce title objects.Although FIG. 37A shows the factory output as title objects, anotherembodiment may only produce a single title, and yet another embodimentcan produce great quantities of titles to fulfill a quota.

Title trading is supported by the title technology and the applicationsthat process titles. Trading between parties can be accomplished in manydifferent ways and involve any number of technologies and techniques.Referring now to FIG. 37B, a simplified diagram of a digital lockboxcomponent is shown, according to one embodiment of the invention. Inthis example, digital lockbox component 3710 is used as a securecontainer for the title objects that are being traded between party Aand party B. Digital lockbox component 3710 further comprises two secureareas that contain the title objects for trade, party A's title objects3716 are stored in drawer 3712, while party B's title objects 3715 arestored in drawer 3714. Digital lockbox component 3710 further permitsinspection by either party into the contents of the lockbox in order foreach to verify the title objects and approve or cancel the trade.Digital lockbox component 3710 would not permit ownership to betransferred and only permits viewing of sample content, or of thecontent permitted by a redemption method (e.g. content legally shared).When both parties have confirmed the trade and approved of title objects3716 and 3715, digital lockbox component 3710 claims ownership over alltitle objects in the lockbox, and then transfers ownership to therespective party. Transferring ownership involves delivering titleobjects 3716 and 3715 to the appropriate title manager 3718 and 3720 andsubsequently having title managers 3718 and 3720 claim ownership fortheir respective party. Digital lockbox component 3710 in this case issimilar to a 3^(rd) party escrow system by providing a substantial levelof guarantee to both parties involved in the trade. For instance, if anypart of the trade failed during the claim process, digital lockbox 3710can rollback the entire trade. Digital lockbox 3710 can also provide alegal record of the trade to all parties involved in the trade. As shownin the example, the contents of the trade can be one or multiple titleobjects.

In another embodiment, digital lockbox component 3710 supports atransfer in which party A intends to give party B the title objects withnothing expected in return. For example, party B could sample thecontent and review it before accepting the transfer. The claim processfor the title objects would remain the same and digital lockboxcomponent 3710 can provide a record of the transaction. In yet anotherembodiment, digital lockbox component 3710 can support: multi-party,dependent trades, nested-trades. In yet another embodiment, digitallockbox component 3710 may support complex trades involving servicelevel agreements, insurance, legal recourse, guarantees, and contentintrospection. For example, a highly confidential trade can beimplemented with special content inspection rights provided throughdigital lockbox component 3710. This would provide both parties with theability to view the confidential content for the duration of the tradenegotiations under special circumstances, such as viewing directly usinga controlled application similar to that provided by digital rightsmanagement software.

In another embodiment, a simplified trade can be executed directlybetween two parties by having title manager components 3718 and 3720simply transfer title objects 3716 and 3715, and subsequently have thereceiving title manager 3718 and 3720 claim ownership over therespective title objects 3716 and 3715. In yet another embodiment, atrade can be executed directly by title manager components 3718 and 3720acting as secure agents. An established protocol can be used by titlemanagers 3718 and 3720 to securely trade the title objects. For example,a Boolean circuit can be utilized by the title managers. In anotherembodiment, security ownership indicia associated with each title objectcan be updated according to specific title authentication techniquesemployed by each respective title objects 3716 and 3715.

Although the structure and management of titles as described herein maymake specific or general references to certain technologies such as XML,other technologies may be available. Title structures can be representedin any number of formats, and management or lifecycle processes can beimplemented in any number of ways. For example, a title object and itsmanagement maybe implemented directly in computer executable code. Thistype of title object can be an effective method for creating titleenabled mobile code, self-executing title objects, digital robots, andcrawlers. In this example, using the title object can providesignificant benefits in that trust and integrity can be transmitted withthe mobile code. In the example where the title object is self-executingcode, the title object can implement title creation functions to morphor transform itself. In another embodiment, a title object can bedescribed in a scripting language and executed as required. For example,a title object can be described and implemented as a Javascript programand embedded within a web page. The Javascript program would comprisenot only the title structure, but also the logic to process the titlessuch as implementing the rules and redemption methods. The Javascriptcode can be used to embed titles in a web page and participate in thetitle transaction ecosystem.

In another embodiment, title objects and management components aredirectly embedded into hardware. For example, a title object can bestored on a smartcard device along with a secure management componentthat is responsible for processing and updating the title object'ssecurity indicia. A user would subsequently insert the smartcard into aterminal in order, among other things, to guarantee transactionvalidity. The title object's security indicia would be securely updateddirectly on the smartcard, as a security precaution. In another example,management components are implemented as firmware in hardware computingappliances (i.e., firewalls, consumer set-top boxes, etc.), or inportable hardware tokens that can be attached to computing devicesthrough direct interfaces, cables or wireless connections.

F. TITLE PROTOCOL AND AUTHENTICATION

In another embodiment, a title protocol is employed for communicationbetween systems participating in a title based transaction. Referringnow to FIG. 38, a simplified title transaction flow is shown, such asthe redemption of a title to obtain content. In one embodiment, thetitle transaction components operate on separate computing devices. Inanother embodiment, the title transaction components operate on the samedevice. For example, the functionality of title manager 3804 can beoperated directly on consumer device 3802 as a complete application.Likewise, the functionality of content proxy 3806 can be operateddirectly on content server 3812. Furthermore, this transaction flow canbe used to assist in the description of the protocol requirements, andadditional transaction flows are intended to be supported by theprotocol.

The components depicted in FIG. 38 may communicate using protocol 3801.In one embodiment, protocol 3801 is a layered protocol whereby a titlespecific protocol must operate on top of another underlying protocol,which may also run on top of another protocol. For example, protocol3801 may comprise a SOAP message which uses the HTTP protocol forcommunication over a TCP/IP network. In another embodiment, protocol3801 can be the title protocol expressed in a format communicateddirectly over a TCP/IP network. In this embodiment, the protocol 3801can be implemented with a complete set of specifications in a similarfashion to HTTP. This implementation can include protocol messagestructures, choreography, standard command languages, and extensibleconstructs. As and example, protocol 3801 can be implemented as anotherstandard Uniform Resource Locator (URL) such that it can be specified ina format similar to DAXP://transaction.example.com where DAXP is theprotocol reference. In this case DAXP is only used as an example andcould refer to the Digital Asset eXchange Protocol. In anotherembodiment, protocol 3801 comprises a mixture of protocols as requiredfor communication between the various components. For example, consumerdevice 3802 can be a mobile device that uses a binary representation ofprotocol 3801 and communicates using an RF protocol to title manager3804 and content proxy 3806. In the same transaction flow, the remainingcomponents can communicate using protocol 3801 expressed as a SOAPmessage. In one embodiment, protocol 3801 can be used for establishingdynamic and policy controlled connections in existing networkinfrastructures, such as control signals for packet switching networks,content distribution networks, load balancing systems, and also forestablishing security associations in secure protocols such as IPSec andIPv6.

Protocol 3801 can be used in other circumstances and not just forcommunication between devices over an external network such as theInternet. In another embodiment, the protocol can be implemented withina device for communication between components. For example, in anembedded implementation such as an electronically controlled machine ina manufacturing application, the protocol 3801 can be implemented forcommunication between discretely operating components. This can includeretrieving control sequences and operating independent machineapparatus. The protocol can accommodate both synchronous andasynchronous messaging processes such that sequences of events can betriggered as required as well as on-demand, or as available.

In one embodiment, consumer device 3802 is used to communicate theredemption request to title manager 3804. Title manager 3804 performstitle processing and returns a title command to the consumer deviceredirecting the consumer to the content. Consumer device 3802communicates the title directly to content proxy 3806, whichsubsequently makes a request to a trusted resolver 3808 in order tovalidate and authenticate the title. In this embodiment, resolver 3808is a separate component. In another embodiment, the resolverfunctionality may be incorporated directly into the content proxy.

Resolver 3808 both validates the title (by ensuring that rules areproperly executed) and also to authenticate the title. In oneembodiment, in order to properly authenticate the title, resolver 3808communicates the title object to the state server 3810. State server3810 subsequently authenticates the title object using an authenticationtechnique specified by the title and supported by state server 3810. Theauthentication process may further involve security indicia includedwith the title object. The endorsement process is responsible forplacing the security indicia in the title object. In one embodiment,state server 3810 returns the authentication response to resolver 3808along with updated security indicia for the title. If the title isauthentic and valid, resolver 3808 communicates the updated securityindicia to title manager 3804 and responds to the original request bycontent proxy 3806.

Upon successful authentication, content proxy 3806 permits the requestthrough to content 3812 which is then returned to consumer device 3802.If the transaction should substantially fail, and consumer device 3802cannot communicate with content 3812, an error message may be returned.In one embodiment, the error message is substantially communicated toall participating parties to insure an orderly rollback of thetransaction, if needed.

In another embodiment, multiple titles may be involved in a transaction.For example, a consumer may want to redeem multiple content objects,each comprising a separate title object, or redeem only one title objectrequiring the presentation of another title object for identity andauthorization. In yet another embodiment, the intermediary parties andsystems involved in a transaction may also be required to present titlesto other systems with which they communicate with during the transactionflow. These titles can be used to authenticate the intermediaries andsystems involved. For example, resolver 3808 in FIG. 38 may be requiredto present a ticket to state server 3810 in order to authenticate it.

FIG. 39 depicts a simplified structure of title protocol 3801 used forcommunication during a transaction flow, as shown in FIG. 38. Messagecomponent 3902 comprises header component 3904 and body component 3906.In one embodiment, message component 3902 is a container element for theheader and body components and may contain additional properties asrequired by the underlying protocol used to carry the message. Forexample, title protocol 3801 can be implemented as a SOAP message thatis bound to an underlying protocol such as HTTP. In this example,message component 3902 is a SOAP envelope element, header component 3904is a SOAP header element, and body component 3906 is a SOAP bodyelement. In another embodiment, message component 3902 can explicitlycomprise both the header and body components. The combined message canthen be encapsulated directly in a SOAP body or other underlyingprotocol format. Although the examples described herein follow astructure that is suited to the XML based SOAP protocol, this is simplyto demonstrate the protocol requirements for communications andexpression of details required in a transaction. Title protocol 3801 canbe implemented in any number of protocol formats such as directly usingSMTP, TCP, UDP or another protocol.

Header component 3904 may be used to contain transaction and systemspecific information that will be processed by some or all of theparties involved in the transaction flow. The header information can beitems such as action identifiers, transaction type specifications,routing information, remote commands, and security classifications. Bodycomponent 3906 may be used to contain the transaction detail such astitles involved in the transaction.

FIG. 40A is a simplified diagram of header component 3904 as shown inFIG. 39. It is further comprised of descriptor component 4002, sessioncomponent 4012, recipients component 4014, responsemethod component4016, routing component 4018, commands component 4020, andtransactionintegrity component 4022. Descriptor component 4002 furthercomprises a transactionid component 4004, actiontype component 4005,transactiontype component 4006, sequenceid component 4007, securityclasscomponent 4008, priority component 4009, lifespan component 4010, andtitleaware component 4011.

Descriptor component 4002 may be used to describe system relatedproperties associated with the transaction. Transactionid component 4004may provide an identifier for the transaction that can be used fortracking purposes, and can also be used to maintain state of thetransaction. The identifier can be a GUID or some other form ofidentifier supported by the applications in the ecosystem. Actiontypecomponent 4005 may identify the action that the protocol is initiatingand can be a textual label specifying an action such as ‘redeem’,‘delete’, or can be a formal identifier used within the titletransaction ecosystem such as an object identifier or URI. Actiontypecomponent 4005 identifies the type of action being performed by therequesting application and may also be used as an identifier in order toinitiate particular actions in applications such as triggering trackingand routing. Transactiontype component 4006 may specify the type oftransaction that is being conducted, such as identifying thistransaction as an ACID transaction. By indicating an ACID transactionall participating applications in the transaction flow must maintain arecord of the transaction and also provide the ability to rollback thetransaction if required. Transactiontype can comprise a simple indicatorof the nature of the transaction and it can also include granularcontrol instructions over the transaction. For example, thetransactiontype component can reference transaction processes that mustcomplete before the transaction is successful and if any process failsto complete, the entire transaction is rolled back. In another example,certain processes can be required to complete where other processes canbe optional. In this example, a transaction process such as anasynchronous notification message need not complete for the transactionto complete successfully.

Sequenceid component 4007 may provide an identifier for a transactionsequence that this particular transaction object is a member of in setor chain of transactions. In one embodiment, sequenceid component 4007specifies a numerical order for the processing of this transaction, orprovides a more sophisticated identifier such as a hierarchicaltechnique. Securityclass component 4008 may identify the securityclassification associated with the transaction. The classification maybe understood, interpreted, and acted upon by all applications thatprocess the transaction. In one embodiment, the classification is anumerical ordering specifying a security setting from low to high. Inanother embodiment the securityclass component 4008 specifies a set ofparameters or instructions for processing such as indicating thesecurity classification of devices permitted to receive and/or processthe protocol message. For example, specifying a government securityclassification. Priority component 4009 may indicate a priority or classof service that should be applied to the processing of this transaction.In yet another embodiment, priority component 4009 is a textual label toindicate a priority level. This component can maintain service levelagreements or providing quality of service guarantees. For example, atransaction object with a high priority level can be placed at the headof the queue for faster response or priority transmission.

Lifespan component 4010 may specify how long a transaction should live.This comprises controls on the processing of the transaction, such thatit must be completed within a specified time period, or must becompleted within a specified number of steps. Lifespan component 4010can specify a time such as a UTC time, and/or can specify a numericalnumber, or some other lifespan indicia that would be understood byapplications in the title ecosystem. For example, the minimum andmaximum number of devices that a protocol message must traverse in anautomated fulfillment application. In this example, the fulfillmentprocess can be automated by a title object traversing a network offulfillment devices using the protocol 3801 for communication. The titleobject traverses the network to each device in search of fulfillmentoffers. The depth of the traversal is controlled by lifespan component4010 before the title object discontinues its search. Titleawarecomponent 4011 may identify if the source device or application is titleaware (such that they understand and process titles directly), allowingthe initiation of certain processing. For instance, an application thatis not title aware may require assistance from proxies in handling titlebased transactions.

Session component 4012 may specify a session identifier to be associatedwith the transaction. The session identifier can be any type ofidentifier used by the processing applications to uniquely identify thesession. For example, in web server applications a session identifier iscreated when a user logs into the web server. Session component 4012 maypermit a set of transactions to be related and tracked to a particularsession.

Recipients component 4014 may identify the parties that should receiveand process the transaction. It further comprises identifiers for therecipients in compliance with the network protocols that are handlingthe transaction. In one embodiment, the recipients are identifiedthrough domain names. In another embodiment the recipients areidentified through URLs. In another embodiment, the recipients areidentified by using titles. The structure of recipients component 4014may be such that one or many recipients can be identified. Furthermore,a group of recipients can be identified such as in broadcast ormulticast situations.

Responsemethod component 4016 may specify the technique and address ofwhere to direct the response to this transaction. This component allowsthe support of asynchronous message responses such that the response toa transaction can be directed through different channels. In oneembodiment, the original transaction is received through a SOAP messageover HTTP. Once the transaction is completed, the initiator of thetransaction may require that the response be sent through anotherchannel such as over SMTP. In another embodiment, the initiator may alsoindicate that the response be sent back through the original channel(such as HTTP) as well as through another channel (such as SMTP).Multiple response methods can be indicated in the responsemethodcomponent 4016. In another embodiment, the responsemethod can specifythat no response is required and can be used to control one-way andtwo-way communication. In another example, the responsemethod 4016 canspecify a timed response, such that a response will not be initiateduntil required by the requesting device or application. Routingcomponent 4018 comprises instructions on how the transaction is to berouted through intermediary or participating parties. The routinginstructions should be understood, interpreted, and processed by alldevices and applications that receive the transaction.

Commands component 4020 may specify commands to the receivingapplication or applications of the transaction object. These commandswill be formatted in a manner consistent with the command languageunderstood by the receiving application, or applications, or devices.For example, scripts may be included such as XSLT, Javascript, or otherscripts and command languages. This component allows additionalinstructions to accompany the transaction. In another embodiment, thecommands component 4020 can be used to implement callbacks. In oneembodiment, the commands component 4020 can be combined with the routingcomponent 4018 for flexible and powerful network control. Referringagain to FIG. 40B, an example can comprise routing instructions inrouting component 4018 that specifies a path through a network, and thecommand component 4020 can relay commands to devices in the path. Inthis example, the commands can be used to apply network configurationchanges in support of dynamic quality of service parameters. Thisembodiment can be used to effectively support a policy based network.Likewise, this embodiment can also be used to reconfigure tools inautomated machinery and perform re-tooling duties on a scheduled basis.

In another embodiment, protocol 3801 can be combined with title objectsto create efficient and effective robots or remote control objects toautomate tasks and implement intelligent networks. Routing and commandstructures along with protocol 3801 can be combined with title objectrules and redemption methods for smart network traversal, instructionrelays, dynamic communications, information gathering and logicprocessing. For example, title objects are provided with a mechanism andlanguage for communication and collaboration with other title objects onthe network. In another embodiment, title objects and protocol 3801 canalso utilize dictionaries and dictionary components as containers andservers for logic that the title objects and protocol messages require.This permits the title object and protocol message to remain small whileproviding the ability for the object and/or message to retrieve logic asrequired and in the format necessary for the processing environment. Forexample, a protocol message 3801 contains command references to a remotedictionary component 4032 as depicted in FIG. 40B, as the messagearrives on device c 4028; the dictionary is queried to obtain thecommand logic. The logic is then executed on device c 4028. In anotherembodiment, the title object and/or protocol message can utilize thedictionary to transform into processing instructions or code that iscompatible with the current device.

Transactionintegrity component 4022, as shown in FIG. 40A, may providesecurity indicia to verify the integrity of the transaction. Thesecurity indicia can be the result of a cryptographic computation suchas a SHA-1 hash result. Transactionintegrity component 4022 may indicatethe technique used to render the security indicia, and may furthercomprise options, or be used in conjunction with or instead of theintegrity checking capabilities of the underlying protocols. Forexample, the SSL protocol provides integrity checking as the transactionis transported over the network. However, transactionintegrity component4022 may further provide end-to-end integrity checking between thecommunicating applications and even through intermediaries, whereas theSSL protocol cannot. In one embodiment, transactionintegrity component4022 would indicate the specifics of the integrity checking such as anintegrity check on the entire message 3902, or on the header 3904, or onthe body 3906, or separately on the header 3904 and the body 3906.

Referring now to FIG. 40B, the routing of protocol messages betweendevices is shown, according to one embodiment of the invention. Forexample, a message originating on device A 4024, is routed to device C4028 as required in the routing instructions. The protocol message isprocessed at device C 4028, routed to device B 4026, then routed todevice D 4030, subsequently routed back to device B, and then finallyback to the originating device A 4024.

At each step in the network traversal the protocol message can beprocessed by devices, including the title objects that may be containedin the message. In another embodiment, the processing can be intelligentin that protocol messages and title objects may execute a learningprocess. That is, they gather information and properties from eachdevice in order to make smart decisions on the routing method and path.The protocol messages as they are executed on processing devices cancontain routing instructions that are triggered on events. For example,as the protocol message arrived at device B 4026, its processing caninclude information gathering, such as identifying additional devices inthe proximity that meet the order fulfillment requirements and servicelevel agreements. Based on the information gathered and the routinginstructions, a decision can be made to route to device D 4030.

Referring now to FIG. 41, a simplified diagram of a body component, asshown in FIG. 39 is shown. Body component 4102 is further comprised oftransactiontitles component 4104, transactionparameters component 4106,and transactioncontents component 4108. Transactiontitles component 4104may comprise titles of transaction participants. For example, it maycontain the tag of a consumer who has initiated the transaction usingconsumer device 3802, as shown in FIG. 38. Transactiontitles component4104 can comprise authenticating material for the title owner. Forexample, if a title involved in the transaction is a ticket, then theowner of the ticket may need to be authenticated. The transactiontitlescomponent 4104 can relay the necessary security indicium that resultedfrom the owner authentication process. In this example, the recipient ofthe protocol message can rely on the authenticating indicia based on apre-established trust relationship thereby eliminating the need tore-authenticate the owner through a separate challenge-response process.In another embodiment, the owner of the title may need to be directlyverified in order to redeem the title. For example, if a resolvercomponent 3808 receives a title object such as a ticket, it may berequired to directly authenticate the owner. This can result in a set ofprotocol messages being sent in a challenge-response conversation sothat the owner can properly authenticate them self. Authentication canoccur within the constraints specified by the title object, such asusername and password, public key cryptography, biometrics, etc.

In another embodiment, transactiontitles component 4104 may only containstubs that reference titles. This method is supported by the titleobject in that the stub can reference the title to which it isbound/attached and that may be stored remotely on another device. Thistechnique can be effective in reducing the size and verbosity of theprotocol 3801. As an example, an owner may have many titles thatrepresent the same currency and denomination in their wallet. The onlydifferentiating factor between the titles is the authenticator stub. Forcommunication purposes it could be inefficient to transport all titlesover a network such as a wireless RF network. In this instance, thestubs could be sent rather than the entire title. The stub elementsreference a title using their binding components. In another instance, asingle copy of the title can be sent along with all the stubs necessaryfor the transaction.

Transactionparameters component 4106 may specify all the arbitraryparameters or properties associated with the transaction. For example,parameters can specify a particular transform that should be applied tothe result of a query transaction to title manager 3804, as shown inFIG. 38. Transactioncontent component 4108 may contain all the contentassociated with the transaction that the applications need tocommunicate.

Communication channels and discovery are essential elements for supportof the protocol 3801. As mentioned previously, the protocol 3801 can beimplemented on top of existing protocols and existing communicationchannels such as TCP/IP, RF networks, and the Internet. Discovery is theprocess whereby devices, applications, and title objects can find andlocate each other using various identity, naming, and locator schemes.The discovery mechanism can be implemented using a variety of techniquesdepending on the environment where the protocol 3801 is operating. Forexample, the discovery technique can differ significantly between theInternet, embedded devices, and locator systems such as GPS.

Referring now to FIG. 42, a simplified diagram of a discovery processthat can be implemented on various networks is shown, according to oneembodiment of the invention. Naming and registry host 4202 identifiesvarious devices by resolving names to network addresses. Title publisher4204 locates the address of the state server 4206 by communicating withthe naming host 4202. Once the title publisher 4204 has obtained theaddress, it can then communicate directly with state server 4206 usingthe network channel supported by the computing devices on which thetitle publisher and state server operate. Likewise, title manager 4208can locate a remote lockbox 4210 by communicating with naming host 4204.In another embodiment, naming and registry host 4202 can be a network ofnaming devices that communicate and propagate address resolution tables.

Referring now to FIG. 43, a simplified diagram of a discovery andchannel technique is shown, according to one embodiment of theinvention. In this embodiment, all communication takes place through acentral host or central host network 4302. Title publisher 4304 startsthe communication and originates a protocol message to state server 4306using the state server's name which is then sent to central host 4302for resolution and delivery. Central host network 4302 would beresponsible for resolving the state server's name to a network addressand delivering the protocol message. In this example, the address ofstate server 4306 can be static or dynamic depending on the networkimplementation. In this embodiment, the protocol can be implemented overnetworks such as instant messaging and electronic mail.

Referring now to FIG. 44, a simplified diagram of a dynamic discoveryand channel technique is shown, according to one embodiment of theinvention. In this example, the process whereby the title publisher 4402discovers the state server 4404 is accomplished dynamically through abroadcast or multicast query, initiated by the title publisher 4402, onthe network. Responses are returned, including a response from the stateserver 4404. Title publisher 4402 analyzes the responses and theninitiates communication with the state server 4404. This embodiment isrepresentative of a peering relationship between all devices on thenetwork such as on a peer-to-peer network. Discovery in the peeringrelationships is established through network queries and responses. Inanother embodiment of the peering relationships, discovery can beaccomplished through physical proximity, such as in the case of wirelessnetworks. In this example, discovery would occur through standardwireless protocols, transmitters, and receivers whereby devices woulddiscover other devices within close proximity such as in IEEE 802.3bwireless local area networks, Bluetooth personal area networks, andinfrared transceivers. Protocol 3801 can take advantage of roamingcapabilities within these types of networks to discover and utilize thecapabilities of a distributed and diverse network. Trust can be animportant element in the network and is described later in the documentand also as an aspect of the authentication process.

The transaction flow and protocol may rely on authentication of titlesto properly identify parties involved in a transaction, as well asevaluate the trust that should be placed on a transaction. Asillustrated in FIG. 38, a title is redeemed and authenticated by stateserver 3810. The authentication technique employed by state server 3810can enable transaction processing, as well as maintain the authentic,valid, and unique properties of titles. For example, state server 3810is substantially responsible for endorsing and authenticating titles,and can also participate in the transaction flow by preserving statebetween transactions, as well as implementing guarantees, or othertransaction logic such as notification and callbacks. The endorsementprocess provides a title or set of titles to state server 3810 forcertification (i.e., proper identification and authorization forcirculation). State server 3810 may then apply an endorsement process inorder to create unique security indicia that may be applied to the titlebeing endorsed. State server 3810 may also apply an authenticationprocess in order to both authenticate and update the security indicia.

Referring now to FIG. 45, a simplified diagram of an endorsement andauthentication process is shown, according to one embodiment of theinvention. New titles generated by title publisher 4506 are notgenerally certified or recognized in the title ecosystem, since theylack authenticator stubs. In general, new titles are sent to stateserver 4502 for endorsement using protocol 3801. State server 4502performs the endorsement process and creates the unique security indiciafor all the titles being endorsed. State server 4502 then stores thestate of the current security indicia in state collection 4504, andsubsequently returns the endorsed titles to the title publisher 4506 forfurther processing, such as distribution to a title manager. In oneembodiment, content within the protocol message comprises a copy of thetitle or titles to be endorsed. In another embodiment, state collection4504 is a database of current security indicia for each title incirculation.

In another embodiment, when a title is used (for example, during aredeem action), the title is presented to state server 4502 forauthentication by resolver 4508. State server 4502 performs theauthentication process and verifies the security indicia containedwithin the title to that of the current state maintained in the statecollection 4504. The security indicium for a title is contained in thetitles authenticator stub.

State server 4502 may also perform endorsement and authentication assupported by the title transaction ecosystem. A variety of techniquesand algorithms can be supported by the title technology, and thetechnique and algorithm employed on a particular title can besubsequently conveyed to state server 4502 for authentication. In oneembodiment, a chained hash mechanism, similar to PayWord, is used fortitle authentication. In another embodiment, the chained hash may begenerated by repeatedly hashing an initial value v which may includetitle information combined with a random number or other appropriatedata using a cryptographically strong hash function H such as MD5 orSHA-1. The first iteration of the chained hash algorithm gives h0=H(v).The second iteration gives h1=H(h0). The nth iteration gives hn=H(hn−1)where n represents the desired length of the hash chain. This hash chainof length n may represent any value within the system from the maximumnumber of redemptions allowed by a title to the maximum number of usersconnected to a system, or any other value required by the system. Inanother embodiment, v may be composed of a random value and a hash ofthe title to later be used for title integrity verification.

In another embodiment, the state server component may generate hn andsecurely store n and the value v that was used as the initial hash valuefor h0. The value hn may then be set in the authenticator stub for thetitle along with the name of the hash algorithm used to create hn. Inone instance, the client may then later present the title uponredemption where the state server may extract the value hn from theauthenticator stub along with the hash algorithm name specified by thatstub. The state server may then look up its stored values v and n andcompute hi=Hi(hi−1) where h0=H0(v) and i={1, 2, 3, . . . , n}. The valuehn would be checked for equality with hi and if equal, the title wouldbe authenticated. The server may then store n−1 in place of n, generatea new authenticator stub containing hn−1 and the name of the algorithmused, and return that stub back to the client where the title may beauthenticated again using the above process as long as n>0.

In yet another embodiment, state server 4502 generates the hash asdefined above and set the values hn, and ye along with the name of thehash algorithm used in the authenticator stub, where ye is the encryptedvalue v. The state server would only need to store n in this embodiment.Upon redemption, the client would present the title with theauthenticator stub containing ye, hn, and the name of the hash algorithmto use. The state server component may then decrypt ye to get vd andcompute hi=Hi(hi−1) where h0=H0(vd) and i={1, 2, 3, . . . , n}. Thestate server component would then verify hi=hn and if true, the titlewould be authenticated. The server may then store n−1 in place of n,generate a new authenticator stub containing hn−1, ye, and the name ofthe hash algorithm used, and return that stub back to the client wherethe title may be authenticated again using the above process as long asn>0.

In yet another embodiment, the client is responsible for generating thehash chain. In one instance, the client generates the value v using thetechniques described above or another appropriate method. The clientthen computes the hash chain hi=Hi(hi−1) where h0=H0(v) and i={1, 2, 3,. . . , n}. The resulting hash chain={h0, h1, h2, . . . , hn}. Theclient sends its credentials, h0, and the name of the hash algorithmused, to the state server component. The state server component verifiesthe client's credentials and stores h0 in its secure data store. Upontitle redemption, the client sends the title with h1 and the name of thehash algorithm embedded in the authenticator stub to the state servercomponent for verification. The state server component retrieves h0 fromits secure data store and hashes h0 using the algorithm indicated toproduce h1*. The title is authenticated if and only if h1=h1*. The stateserver component then replaces h0 with h1 in its secure data store. Theclient can no longer use h1. Note that in this embodiment the clientwill always supply hi and the state server component will always storehi−1. The ith redemption consists of the value hi supplied by the clientwhich the state server component can verify using hi−1. Each suchredemption requires no calculations from the client and only a singlehash operation by the state server component.

In another embodiment, when a chain of hashes expires, such as n=0, thestate server 4502 can automatically perform a re-endorsement of thetitle and create a new chain. The re-endorsement can occur selectivelyand as permitted on the particular title.

In another embodiment, a random value technique is applied toauthenticate a title. A random value is generated by the state server4502 and placed in the authenticator stub. The state server 4502 alsomaintains a record of the random value in its state collection 4504. Therandom value would be changed by the state server every time the titleis authenticated and only the title object with the correct random valuewould be valid.

Referring now to FIGS. 46A-B, a simplified diagram of a hashauthentication scheme for divisible cash is shown, according to oneembodiment of the invention. In one embodiment, a title's value isrepresented by a tree where each node represents a denomination of thetitle and the root node is the sum of all its child nodes equal to thetotal value of the title. For example, in FIG. 46A, a title representinga twenty dollar bill in US currency is shown. The value of the root nodeis $20 as represented by 4602, and has two immediate child nodes eachvalued at $10 as represented by 4604. Each of the $10 nodes would havetwo $5 nodes as represented by 4606. Each parent node is a hash of itsimmediate child nodes such that each $5 node is hashed with some initialrandom values and its parent node, the $10 node, is a hash of its two $5child nodes. If customer A wishes to pay merchant B with part of atitle, then A would present B with the hash of the nodes A wishes tospend.

Referring now to FIG. 46B, if A wishes to spend $15 of a $20 node, thenthe hashes of the nodes for $10 4608 and $5 4610 would be given to B.When a node is spent, it and its forefathers may not be spent again. Inthis example, A would be left with a single valid $5 node 4612representing the amount remaining after payment. When B deposits thepayment into the bank C, C only needs to verify that the $10 and $5nodes can be hashed back to the root $20 node. If true, C may record thenodes as spent and issue payment to B

In another embodiment of the authentication technique and process, theauthenticating security indicia can be separated across multiple titleobjects. In this instance, two or more title objects would need to bepresented in order to authenticate any one, some or all of the titleobjects. For example, a split-key technique can be applied such that thesecurity indicia is securely broken into multiple parts and correctlyapplied to a set of title objects in the endorsement process. The titleobjects can be distributed normally to various parties. In thisembodiment all of the parties would need to present their title objectsin order to redeem content or gain access to an asset. In one variationof this method, the security indicia can be securely split among varioustitle objects such that only some of those title objects need to bepresented and not all. For example, the security indicia can be splitacross three title objects, but only two title objects need to bepresented for authentication. In another variation, the techniqueapplied for authenticating a title can be dependent upon another titleor set of titles. For example, the security indicium that authenticatesa title can be generated based upon direct references to another titleor set of titles. The state server 4502 in this case would reference theother titles and perform a serialized authentication process. Thesemethods can be effective for implementing secondary authenticationpolicies such that two parties must be present before access is granted.

In another embodiment of the authentication technique and process,several layers of security indicia can be applied to a title object. Inthis instance, a title object can be authenticated at various levelsusing different security indicia, and can in turn implement differentauthenticating techniques for each level. For example, in a three stageauthentication process, a title object can be endorsed three separatetimes using different techniques with each technique applying morestrict guidelines and stronger security. In this example, the thirdstage endorsement can be utilized for insecure network traversal; thesecond stage for more secure network traversal and for limitedredemption of the title; the first stage for confidential processing andfull access to title redemption methods. This multi-stage endorsementand authentication process can be effective in mixed environments wherethe title object can be routed and authenticated in an insecure publicenvironment without comprising the security indicia that is used forauthentication and verification in secure environments.

In another embodiment, a title object can be endorsed by multiple andindependent state servers. This permits a single title object to beendorsed (i.e. certified) by separate parties, domains, entities, etc.thereby permitting use of the title object in a particular environment.In one example, the multiple endorsements can relay a particular trustabout the title object. For instance, an ecosystem of computing devicesthat implement title enabled applications may be configured such thatthey trust only state servers that are identified and reside in theecosystem; as well as trusting only titles endorsed by these stateservers. In order for these applications to trust a title thatoriginated outside the ecosystem it can be re-endorsed by the stateservers inside the ecosystem. In this example, the title object wouldhave two endorsements and two authenticator stubs: one from theoriginating state server; and the other from the state server operatingin the ecosystem. For authentication, applications in the currentecosystem would rely on their state server for authentication. Inanother variation, the state server inside the ecosystem canauthenticate the title object itself, and also request authenticationfrom the originating state server outside the ecosystem.

In yet another embodiment, state server 4502 supports a revocation andsuspension process, whereby titles in circulation can be revoked forvarious reasons. For example, if a title has been reported stolen it canbe revoked. Or, if a consumer has not met the requirements for thecontinued use of a title it can be suspended until the requirements aremet. In this example, a revocation or suspension protocol message issent to state server 4502 from a valid and trusted source. State server4502 will then revoke or suspend the title in question and maintain thisin the state collection 4504. In one example, revocation can berequested by the owner of the title and in this case the title can bepresented for revocation. The state server 4502 will authenticate thetitle before revoking.

The establishment of trust within the title transaction ecosystem canoccur in several ways. In one embodiment, the participants in a titletransaction establish trust implicitly by trusting the authentication oftitles used in a transaction that have been endorsed and authenticatedby known and configured state servers. For example, as applications anddevices communicate using the title protocol, the titles conveyed withinthe protocol will be authenticated by known and trusted state servers.In another embodiment, trust is established by using trust titlesconfigured on title enabled applications and devices. The trust titlesprovide fine-grained descriptions and instructions on what title objectsare to be trusted and under what circumstances. Trust titles can becreated and endorsed by administrative applications and configured ontitle-enabled applications. The title-enabled applications can thenrefer to trust titles to execute instructions and filters ontransactions that they process to ensure that the titles can be trusted.Trust within a title transaction ecosystem can be established on animplicit or explicit basis, in a peer-to-peer matrix relationship, in aformal hierarchical manner, or in a hybrid fashion depending on therequirements of applications involved in title transactions. In anotherembodiment, trust can be established through the title objectauthentication process as described previously. In another embodiment,trust can be established by utilizing a public key infrastructure orsimilar method such as X.509 and PGP digital certificates. This canoperate in conjunction with digitally signed title objects and digitallysigned stubs. In another embodiment, trust can be explicitly specifiedby a user on a title by title basis, or by configuring a set ofparameters within their profile.

H. FILE SHARING AND DISTRIBUTION

In another embodiment of the title system, titles can be used to managethe access to, sharing and distribution of digital asset. A digitalasset comprises anything that may be stored in digital format (i.e.,documents, pictures, audio, and web based asset). Previous approaches tofile access control are normally based upon the concept of the name andpassword which can easily be propagated among multiple users. In thisembodiment the title is used to easily refer to and control access tothat digital asset.

Referring now to FIG. 47, an example of a system that manages thedistribution and access to digital asset architecture is shown,according to one embodiment of the invention. Although the diagram showsseparate components that maybe operated on separate computing devices,in another embodiment these components can be operated on the samedevice. In one embodiment, the functionality of title manager 4702 canbe operated directly on consumer device 4701 as a complete application.Likewise the functionality of the title redemption system 4704 may existon the title publishing system 4703. Also the term network refers to anymechanism that allows the transfer of data between computing devices.

Referring now to FIG. 48, a high level mechanism for retrieving theasset is shown, according to one embodiment of the invention. The userselects the title object that represents the asset that the user wishesto access 4801. From the user's perspective it may not be known that atitle object is involved, only that an asset is being selected.

The user's title manager will then present the title to the appropriatetitle resolver 4802. The title resolver will reject the title if theauthentication stub is invalid 4804. The system can have an optionalrejection mechanism which can offer a range of responses and possibleactions depending upon the requirements and needs of the asset owner orprovider.

If the authentication stub is valid, then the authentication stub isupdated 4806 and the title object is re-issued to the user 4807. Thisupdate and re-issue process ensures that any copies of the title thatwere made by the user will now be invalid. This means that it is notpossible to copy and distribute a title object among a group of peopleas the first person to redeem the title object will make the othercopies of the title object invalid and thus the other members of thegroup will have no access to the asset.

In another embodiment this ability of the title to manage and controlaccess to the asset can be further enhanced through other mechanisms ofthe title object which for example limit the access of the title to theasset based upon number of uses, time period, time of days and otherappropriate mechanisms that support the business model of the assetowner.

In yet another embodiment the mechanism within a title that supportsdifferent redeem methods enables users who use multiple devices toaccess asset, to have the asset presented to them in the mostappropriate format for the device that the user is using at thatparticular point in time. For example if the user is accessing the assetfrom a mobile phone then the asset could be text based, while if theaccess device is a computer then the asset could be multimedia based.

Referring now to FIG. 49, a process to search for digital asset usingthe title system is shown, according to one embodiment of the invention.Because a title contains a metadata description that describes the assetit is possible to search for asset effectively across a wide domain andfind valid asset. This compares to search systems today that are basedupon text matching systems that do no take account of the context inwhich the text exists. Thus for example a search for a piece of musicbased upon artist name using the title system will result in titles thatpoint to asset rather than pure text based systems which will list textwhenever that artist is mentioned, resulting in a search results that istoo broad for the user to utilize.

In this embodiment of the search process the user selects the titlesearch option 4901. The user is then prompted for the type of asset thatthe user wishes to search for 4902. Based upon the asset type adedicated search form will be displayed 4903, which the user enters thecriteria in 4904. The title search engine will then search for titlesthat meet those criteria 4905 across a single domain or multipledomains. There is an option to check the digital signature 4906 withinthe titles to ensure that they have been published by a valid entity.The title search engine will then return a list of valid titles 4907,and the user has the option of refining the search further 4908, orselecting and previewing the titles of interest 4909.

The multiple redemption methods that titles supports means that thepreview methods used in 4909 can be extremely flexible ranging from asimple description to the ability to access the actual asset with a setof constraints such as view once or only valid for a number of days.Once the consumer has found the asset of interest then a titletransaction can occur 4910 between the user and the owner of the titleobject. Once a user posses a title, which gives them a certain set ofrights to the digital asset, depending upon those rights the user cancarry out a number of transactions with those titles that they own.These transactions being to share the title, to give the title, or totrade the title.

Referring now to FIG. 50, a simplified process for sharing a titleobject is shown, according to one embodiment of the invention. Because atitle cannot be copied and used by two people, the sharing mechanismallows a title object holder to share access to a version of that assetbased upon the rules that the asset holder implements through the titlemechanism.

The mechanism for sharing between user1 and user2 is very simple, user 1has an asset that they wish to share 5001, user 1 selects the title, andselects the share option 5002. Users 1 title manager creates a shadowtitle 5003 if the original title object allows the sharing mode, whichuser 1 sends to user 2 using an appropriate mechanism 5004 such asemail, instant messaging or another digital transport mechanism. Theshadow title is a modified version of the original title object in thata mechanism such as removing the authentication stub is used to indicatethat this shadow title has no rights. In other embodiments the userinteraction could be different, and the functionality to create theshadow title may exist within other elements of the system for examplethe client device or the title publishing system.

Once user2 receives the shadow title, it is stored in title manager5005, and it can now be redeemed by presenting it to the title resolversystem 5006. When the title resolver detects that the title object is ashadow 5007, then using the business rules indicated within the titleitself, or through the asset system, a preview version 5008 of the assetwill be presented to user2 5009. This preview version of the asset cantake many forms including a simple description, a lower quality version,an online version rather than a downloaded version, or a limited useversion based upon time, number of uses or other appropriate mechanisms.It should be noted that in this embodiment it was a one to onetransaction, but in fact could be a one to many transaction weremultiple shadow titles are generated. In another embodiment, the shadowtitle can be stored in title manager 5003 on behalf of the recipientuser2 who may not have a title manager or title-enabled application. Inthis instance, the recipient would have no method or apparatus forredeeming the title. Instead, the title manager 5003 in this examplemaintains the shadow copy and presents an encoded URL to user 1 thatrefers to the shadow copy. User1 then sends the encoded URL to user2using a standard communication mechanism such as electronic mail orinstant messaging. Upon receiving the encoded URL, user 2 clicks on itthereby initiating a redemption with title manager 5003.

This approach to sharing of asset meets the needs of asset owners andproviders to have their legal rights to that asset to be fullyrespected, while providing an easy to use mechanism for the users ofasset to make other users aware of this asset and for them to use thisasset in some restricted form. If the recipients feel that the asset isof value to them then they can purchase the asset.

Referring now to FIG. 51, a simplified process for giving an asset toanother user is shown, according to one embodiment of the invention.With previous mechanisms of purchasing and giving digital asset, therewas always the possible issue that the purchaser would in effect bemaking a copy of the asset, or the name and password to access theasset. With a title based approach it enables asset to be purchased andgiven with no residual copy existing for the purchaser.

In this embodiment of the gift scenario user1 purchases a title objectto give as gift 5101. Once user1 has received the title object into thetitle manager, user1 selects the title 5102 and selects the gift option5103, user1 selects the recipient and has the option to create a giftmessage. User1's title manager presents the title object to the resolverin gift mode 5104. The resolver will validate that this title can begiven as a gift and that optional criteria have been met 5104. Theseoptional criteria can include such features as the asset must have neverbeen accessed by user1. If the title object cannot be given as gift thetitle is rejected and an optional rejection mechanism can occur.

The title resolver will update the authentication stub to invalidate anycopies of the title object that user1 may have 5106, and the updatedtitle object is sent to the user1's title manger which willautomatically send the title object and the associated message touser2's title manger 5108. On receipt of the title user2's title managercan optionally refresh the authentication stub of the title object foradded security. It should be noted that other embodiments of the giftmechanism could be implemented, for example using a lockbox for extrasecurity, or getting the title publishing system to send the titledirect to user 2. An enhanced version of the gift mechanism would be toallow user1 to build an album or collection of digital asset that couldbe given as a gift, in this case the systems would handle the multipletitles. A further embodiment would be the ability to give the titleobjects to multiple people where the payment for the multiple copieswould be handled automatically as part of the gift process.

Referring now to FIG. 52, a simplified process for trading titleswithout valid copies of the title object being left on the parties'machines, according to one embodiment of the invention. In this processthe two users have two titles to trade 5201 & 5202. User1 places theirtitle on a title market place 5203, and user2 finds that title1 isavailable for trade 5204. User2 offers user1 title2 as a trade 5206, anduser1 accepts the offer 5205. It should be noted that this is onepossible embodiment of the mechanism for establishing the trade. Thereis a wide range of embodiments for establishing the trade includingautomatic trading boards, trading bots and simple communication betweenthe parties involved in the trade.

Once a trade has been agreed upon, a mechanism must be provided for thetrade to occur. In this embodiment, a digital lock box is used but therea wide range of options for providing the actual trading mechanism.User1 places title1 into the digital lockbox 5207 and user2 placestitle2 into the digital lockbox 5208. A mechanism then verifies andauthenticates the titles to be traded. Examples include using digitalsignatures, presenting the titles to the issuing site, or giving theusers the ability to view the titles.

Once the titles are verified, they are presented to their respectedtitle resolvers for their authentication stubs to be updated at 5211 &5212. This ensures that any copy of the titles kept by users is nowinvalid for redemption. The titles are now traded 5213 & 5214 anddelivered to the title managers 5215 & 5216.

In another embodiment, the trading mechanism comprises digital tradingcards. In general, the collection and trading of physical trading cardsis very popular. However, implementing a corresponding digital tradingcard system has generally been impractical. One reason may have beenconcerns of piracy. That is, a complex centralized digital rights systemwould be required to log all ownership and securely manage trades.Through the use of the present invention, however, a secure scalabledigital trading card system can be implemented.

Referring now to FIG. 53, a digital trading card architecture is shown,according to one embodiment of the invention. Title object 5301 includesembedded content 5302 comprising a digital trading card. Embeddedcontent 5302 may be displayed through a browser or a dedicatedapplication for displaying the digital trading card. Digital tradingcard 5304 may also use reference content 5303, such that the digitaltrading card can present updated or fresh information. Embodiments ofthis information could include updated sports statistics for sportsbased cards, updated information for game cards or updated multimedia.For example, a digital trading card could be used in conjunction with aphysical trading card. A consumer, buying a physical card 5304, wouldalso be given a unique ID 5305. Upon presentation to digital tradingcard generator system 5306, a digital trading card based upon thecorresponding title is generated.

The mechanisms for generating titles that refer to digital assets can bedivided into two classes, automated systems and user driven systems.Automated systems that interact with established web based systems suchcontent management systems would use dedicated interfaces and suchembodiments of this approach to title generation have been covered byother descriptions. There are a wide range of embodiments for userdriven systems that deliver a functionality that systems deployed to daycannot deliver. In one embodiment, a file sharing system allows users todistribute content easily among their contacts.

Referring now to FIG. 54, a user interface is shown allowing users toshare and manage digital assets sharing, according to one embodiment ofthe invention. My contacts 5401 comprises a list of contacts with whichthe user interacts. For example, the contact list could be a simpleaddress book application or the contact system is a title based system.Contacts may be individuals 5402 or groups of individuals 5403. In orderto share a digital asset, a user would identify a contact, determineappropriate digital asset rights 5406, and generate the title 5407. Atitle object would subsequently be sent to the contact. A previewversion of the asset can be shown in window 5405.

Referring now to FIG. 55, an example of the management of titles and theassociated rights is shown, according to one embodiment of theinvention. Digital asset sharing allows users to easily share digitalassets with contacts while not have to worry about names and passwordsor the underlying file structure. For example, it is possible to clickon contacts 5501, such as a friend or business associate 5502, or groups5503, to discover the assets to which they have access. For each asset,a list of contacts with corresponding rights can also be displayed. Inthis way, it is possible to select a contact 5505 and manage the rightsand title for that contact 5506, subsequently generating a new title ifrequired.

Referring now to FIG. 56, an example of an abstraction layer allowingdifferent groups of digital assets to be presented to different groupsof people is shown, according to one embodiment of the invention. Forexample, if a user has to support multiple web pages for differentgroups such as family, friends, colleagues etc then it can be verylaborious to manage those multiple pages especially if there are sharedassets. FIG. 56 shows how this would be done at an abstract layer. Thereis a collection of digital assets and these assets could be managed inthe title domain or they could exist in other domains such as files, webpage content, emails, bloggers and other forms. Using the title manageror an assistant program the user collects the group of digital assetsand can use a template 5602 to control how they will be displayed. Adigital asset group 5603 has now been created which takes the individualdigital assets and displays them in a formatted way. Titles are thencreated 5604 using previously described mechanism for contacts(individuals or groups) 5605 to access particular digital asset groups.This layer of abstraction combined with the title mechanism provides anefficient and easy way to way to mange multiple digital assets and howthey are accessed by multiple contacts.

I. CONCLUSION

Advantages of the invention include the ability to easily andefficiently manage and share titles over a network such as the Internet.Additional advantages of the invention include creating an ecosystemwhereby digital content providers can offload the burden of managing andenforcing user access rights, yet receive revenue from third partytransactions.

Having disclosed exemplary embodiments and the best mode, modificationsand variations may be made to the disclosed embodiments while remainingwithin the subject and spirit of the invention as defined by thefollowing claims.

1. A rights-based network, comprising: one or more data stores forstoring a plurality of title objects associated with a plurality ofentities, each title object being a digital bearer instrument expressinga plurality of rights which may be redeemed by presentation of the titleobject to one or more title-enabled processes in the network, each titleobject identifying one or more resources associated with the pluralityof rights, the one or more resources being at least partiallydeterminative of how the one or more title-enabled processes facilitateredemption of the rights, each of selected ones of the title objectshaving a state associated therewith; one or more state processes whichinclude an entry for each selected title object which indicates validityof the corresponding selected title object when the entry issynchronized with the state of the corresponding title object; one ormore title protocols deployed in the network and configured tofacilitate communication and transfer of the title objects among theentities; a title manager deployed in the network and associated with afirst one of the entities, the title manager being operable inconjunction with the one or more title protocols to facilitatemanagement by the first entity of first ones of the title objectsassociated with the first entity; and a title resolver deployed in thenetwork, the title resolver being operable in conjunction with the oneor more title protocols and the one or more state processes to determinewhether the selected title objects presented in the network are validwith reference to the states associated with the selected title objectsand the corresponding entries associated with the one or more stateprocesses.